From mueller at syr.edu Sun Jul 1 18:28:00 2012 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 1 Jul 2012 22:28:00 +0000 Subject: [arin-ppml] Statistics for NRPM 8.3 Transfers In-Reply-To: <3AB70F82-7046-452F-98AB-C6077A92682D@corp.arin.net> References: <20120629060025.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.09f2067911.wbe@email17.secureserver.net> <3AB70F82-7046-452F-98AB-C6077A92682D@corp.arin.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD21A772A@SUEX10-mbx-10.ad.syr.edu> John: Good! We all seem to agree that we could use more data on this process. In my proposal for new transfer transparency policy for RIPE, I ask RIPE not only to record transfers and publish the blocks involved as ARIN already does, but also to record when requested transfers are denied on the basis of the recipient not meeting the needs test. This can be done without revealing the identity of the recipient who failed the test. One would get a notice something like: A request received on [date1] to transfer netblock X, currently registered to ASN Y, was denied on [date] due to failing the needs assessment. I think all this information should be published for all transfers/failed transfers, and it should not be optional at all. Such information not only provides important information about the workings of the transfer market, but also raises flags if needs assessment denials get out of hand or are used in a discriminatory manner. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of John Curran > > We're happy to collect any metrics that the community > can agree upon, and would encourage discussion of the > appropriate set. > > Collecting this information for all requests may raise > concern by some parties, and so it also worth considering > which would only be reported on only in the aggregate and > whether some of these should be optional, i.e. left to the > discretion of the recipient whether to be provided. > > Thanks for raising this important topic! > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Sun Jul 1 18:43:08 2012 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 1 Jul 2012 22:43:08 +0000 Subject: [arin-ppml] Transactional transparency Message-ID: <855077AC3D7A7147A7570370CA01ECD21A775A@SUEX10-mbx-10.ad.syr.edu> Let me again express my strong support for Jeff's suggestions regarding transparency and data about transfers. Responding to Tom's assertion that such information would be "unacceptable to most potential market participants," that assertion clashes with standard operating procedure in real estate. You can all find out what I paid for my house, the date(s) it was sold, the identity of the transacting parties, and a lot of other information. Why should IP address holdings be any different? Stock market transactions are also made transparent, especially when "insiders" are involved. This kind of information is known to facilitate, not disrupt or prevent, market transactions. Its availability makes the market more efficient and serves consumer protection purposes as well. Why not a Zillow for IP addresses? http://www.zillow.com/ This ought to be a topic on which all factions can easily agree. It's just common sense. Milton L. Mueller Professor, Syracuse University School of Information Studies Internet Governance Project http://blog.internetgovernance.org > -----Original Message----- > > > > 1. Date of Request for 8.3 Specified Transfer 2. Status of > > Transferring Block (Legacy, LRSA, RSA) 3. Size of Block (/16, /17, > > etc.) 4. Source SIC Code 5. Recipient NRPM Definition: ISP or End > > User 6. Recipient Customer Status with ARIN: Customer or Non-Customer > > 7. If ARIN Customer, date and size of last allocation from the free > > pool 8. Current percent utilization of existing blocks 9. Number of > > Justification re-submissions for transfer 10. Approval or Rejection > > decision 11. Approval or Rejection rationale (codes 1-?) 11. Date of > > Approval or Rejection 12. Facilitator Involvement (yes/no) 13. Price > > paid (US$) > > I agree that more information is almost always better than less -- but I > suspect that you've already overshot the level of information that would > be deemed acceptable to most potential market participants by a very > wide margin. Moreover, even this is not enough. For example, why exclude > the identity of the aspiring buyer and the aspiring seller? With the > possible exception of smallish entities that are both privately held AND > have zero customers (i.e., that have no PA allocations and at most a > very small number of ASNs), every institution that has ever received > resources from ARIN or one of the other RIRs has critically important > "external" stakeholders -- including either or both current and > potential future stock buyers/holders/shorters, and (imo, more important > still), a potentially large number of downstream network service > "customers" -- i.e., entities whose own IPv4 addressing needs often > provided much of the original "justification" that enabled the aspiring > IPv4 buyer /seller to obtain whatever resources are already in their > possession. Surely the network customers whose future service > expectations, and the investors whose future earnings expectations may > be substantially impacted by a network service provider's evolving IP > addressing strategy also have a right to know? Promoting a larger/more > active IPv4 market while simultaneously shielding the identities of > aspiring IPv4 market participants would dramatically reduce whatever > level of market "certainty" that those important stakeholders currently > enjoy -- how can that be justified? > > Also, assuming that "facilitators" are free to differentiate themselves > by adopting different commercial strategies that could in turn > materially affect the outcome and details of the transactions that they > broker in different ways, why should their identities be exempted from > public disclosure? > > > I'm surely missing a half dozen other data elements that are captured > > during an 8.3 but my point is, there is considerable data...will it > > support the notion that 24 months is the correct window? Very loosely > > at best, but it would assist all interested parties in better > > understanding the 8.3 transfer market. Publishing price however is > > going to be an entirely separate debate isn't it? I quietly muse at > > all that would suggest 60 months will permit speculation or hoarding. > > Really? What are you speculating on in the absence of known prices > > and continuous updates? If however, prices are published, now you > > have the basis to speculate as is the case in every open market system > > (real estate, stock market, etc.). > > > > As for other well-established markets, I have thoughts but would > > suggest there are individuals who participate on the PPML better > > qualified to suggest objective models for assessment purposes. > > In that case I guess we'll have to wait for someone who is both (a) > knowledgeable of a potentially illuminating present-day exemplar market > and (b) actually believes that it would be beneficial for IPv4 to be > traded more like a "normal" commodity to speak up. > > For my own part, I am quite familiar with some other markets that are, > IMO, quite relevant and illuminating to the problems under discussion, > but at present those markets provide only a wealth of examples of what > not to do (i.e., if we value stable markets, a stable, self-governing > industry, continued/future growth and prosperity, etc.), and what to > expect if we proceed anyway. > > Regards, > > TV > > > > > Jeff Mehlenbacher > > > > -------- Original Message -------- > > Subject: Re: [arin-ppml] ARIN-prop-176 Increase Needs-Based > > Justification to 60 months on 8.3 Specified Transfers > > From: Tom Vest > > Date: Thu, June 28, 2012 11:59 am > > To: > > > > Cc: Daniel_Alexander at Cable.Comcast.com, arin-ppml at arin.net > > > > Hi Jeff, > > > > Out of curiosity, could you suggest ( at min.) one set of data that > > would be sufficient, in your view, to determine the appropriateness of > > a(ny) IP number resource transfer market, under current or any other > > imaginable policy criteria? How would you define "appropriateness" and > > what sort of data would you need to make such a judgment? > > > > If this question seems too abstract, perhaps you could point us to > > some other, well-established market that demonstrably satisfies its > > own "appropriateness" criteria based on "objective" data that is, if > > not publicly available, at least available to some disinterested > > "appropriateness evaluators"? > > > > Thanks, > > > > Tom Vest > > > > On Jun 28, 2012, at 6:25 AM, > > wrote: > > > >> I have a real concern that the body of data available for > >> assessment is neither comprehensive nor focused on dictating success > >> or failure of the current 24 month justification period. I would be > >> interested in understanding what data will be monitored to determine > >> the appropriateness of current policy for 8.3s. > >> > >> Thanks! > >> > >> Jeff Mehlenbacher > >> > >> > >> Date: Thu, 28 Jun 2012 08:11:24 +0000 > >> From: "Alexander, Daniel" > >> To: "arin-ppml at arin.net" > >> Subject: Re: [arin-ppml] ARIN-prop-176 Increase Needs-Based > >> Justification to 60 months on 8.3 Specified Transfers > >> Message-ID: > >> >> om> > >> > >> Content-Type: text/plain; charset="Windows-1252" > >> > >> Jeff, > >> > >> One of the primary justifications used during the debate of 8.3 > >> transfers claimed that transfers would put underutilized resources to > >> use. By stretching the period to five years, we start trading one > >> underutilized resource holder for another. This is a contradiction to > >> the claimed benefits that everyone was supposed to accept who > >> objected to these transactions. > >> > >> No sooner than section 8.3 was created the policies came in to expand > >> the timeframes. The timeframes have already been expanded before > >> having any data as to the benefits or consequences of the changes > >> that have been made. While I don't claim to know what the magic > >> number should be, I think this change would be irresponsible at this > >> time, based only on the speculations made on this mailing list. > >> > >> I'm opposed to this proposal. > >> > >> Dan Alexander > >> Speaking as myself > >> > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN > >> Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Sun Jul 1 19:17:35 2012 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 1 Jul 2012 23:17:35 +0000 Subject: [arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers In-Reply-To: <20120628030510.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.6d8c08c87a.wbe@email17.secureserver.net> References: <20120628030510.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.6d8c08c87a.wbe@email17.secureserver.net> Message-ID: <855077AC3D7A7147A7570370CA01ECD21A7795@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > I understand your desire to sit tight and assess statistical evidence > before suggesting a longer justification period is required. My concern > with such a strategy is the decided lack of comprehensive transfer > market data. We have only the ARIN Specified Transfer Listing Service [Milton L Mueller] As a social scientist, it seems obvious to me that asking for statistical support for a longer time frame, without allowing an actual, real-world experiment with the longer time frame, is asking for the impossible. The only way to gather "statistical evidence" on the impact of changing the time frame for needs justifications is to allow a different needs assessment time and see how the change affects the quantity and type of transfers authorized. No empirical conclusions can be drawn about the relative merit of a 24-month and 60-month period by looking ONLY at the statistics generated by a 24-month period. That is why I view the request for statistical evidence as a tactic designed to delay or defeat Jeff's proposal. If one really wants to do an experiment, it would probably make more sense to conduct a limited experiment with no needs assessment at all, and see what happens. If one discovered a significant increase in the number of approved transactions, and/or a massive increase in what appeared to be speculative acquisitions, and if either result could not be explained by other variables, it would support the conclusion that the current time horizon constricts the number of transactions in a specific way. In the absence of such an experiment, the only empirical data that might support or refute the change would be a survey of all prospective buyers in which a statistically significant sample of them stated unambiguously that they would participate in the transfer market if the needs period were extended to 60 months; or that their planning horizon for acquiring IP addresses was closer to 5 years than to 2 years. Such a survey would be very difficult to conduct, and you would still be dealing with stated preference rather than revealed preference. But it would be potentially informative. The bottom line is that those calling for statistical evidence have one of two choices: either they must agree to conduct an experiment, or they can abandon the claim that they oppose the proposal for lack of statistical evidence and admit that they just don't want it to happen, regardless of evidence. From mysidia at gmail.com Sun Jul 1 20:32:09 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 1 Jul 2012 19:32:09 -0500 Subject: [arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers In-Reply-To: <855077AC3D7A7147A7570370CA01ECD21A7795@SUEX10-mbx-10.ad.syr.edu> References: <20120628030510.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.6d8c08c87a.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD21A7795@SUEX10-mbx-10.ad.syr.edu> Message-ID: On 7/1/12, Milton L Mueller wrote: > [Milton L Mueller] As a social scientist, it seems obvious to me that asking > for statistical support for a longer time frame, without allowing an actual, > real-world experiment with the longer time frame, is asking for the > impossible. [snip] What kind of method would you propose that ARIN use to conduct such an experiment without changing the policy and risking that the same irreversible damage is done as simply extending the justification period without an experiment? -- -JH From mysidia at gmail.com Sun Jul 1 20:47:21 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 1 Jul 2012 19:47:21 -0500 Subject: [arin-ppml] Statistics for NRPM 8.3 Transfers In-Reply-To: <855077AC3D7A7147A7570370CA01ECD21A772A@SUEX10-mbx-10.ad.syr.edu> References: <20120629060025.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.09f2067911.wbe@email17.secureserver.net> <3AB70F82-7046-452F-98AB-C6077A92682D@corp.arin.net> <855077AC3D7A7147A7570370CA01ECD21A772A@SUEX10-mbx-10.ad.syr.edu> Message-ID: On 7/1/12, Milton L Mueller wrote: > This can be done without revealing the identity of the recipient who failed > the test. One would get a notice something like: > A request received on [date1] to transfer netblock X, currently > registered to ASN Y, was denied on [date] due to failing the needs > assessment. If ARIN publishes a list of these for every day, most stats can be derived, without ARIN having to calculate them. [date1] A STLS-facilitated request was received to transfer direct assignment 192.168.0.0/24; changing from an assignment to an allocation from a transferor who has been named on the request for 15 transfers to date this year, with total XXX ip addresses an average of XXX ip addresses per request, 5 of which were accepted with total XXX ip addresses transferred XXX ip addresses per request, 6 of which are still pending XXX ip addresses pending average XXX ip addresses per request, 2 of which were rejected due to lack of justified need XXX ip addresses rejected XXX average ip addresses per request, 1 of which was withdrawn, and 1 of which was rejected for another reason. (Repeat counts for transferee) -- -JH From mysidia at gmail.com Sun Jul 1 21:00:22 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 1 Jul 2012 20:00:22 -0500 Subject: [arin-ppml] Transactional transparency In-Reply-To: <855077AC3D7A7147A7570370CA01ECD21A775A@SUEX10-mbx-10.ad.syr.edu> References: <855077AC3D7A7147A7570370CA01ECD21A775A@SUEX10-mbx-10.ad.syr.edu> Message-ID: On 7/1/12, Milton L Mueller wrote: > Let me again express my strong support for Jeff's suggestions regarding > transparency and data about transfers. > Responding to Tom's assertion that such information would be "unacceptable > to most potential market participants," that assertion clashes with standard [snip] This is a fair question. New allocations are public knowledge, and so is the organization who received them. Is there any reason that transfers should be treated any differently? I will propose that all 8.2 and 8.3 transfers shall be published when they are completed; including the specific block, network name, size, and handle of the transfer recipient. And there shall be no secret with regards to when a transfer request is completed. Transfer requests that are cancelled, withdrawn, or rejected are another matter -- the information should be available and recorded by ARIN, but possibly details filtered, such as failed recipient, failed transferrer, and exact block (although its size should be published), since the transfer wasn't completed; ARIN doesn't need to unnecessarily embarrass requestors who have made an error, and will likely be back to make a new request or revision, once they have understood the problem. We don't need for detailed contact details to be included for transferred blocks, these should already be included in the WHOIS service before and after the transfer, at least when combined with archives of past WHOIS data, and someone who has a legitimate cause to research these therefore already has the info available, and there are some anti-spam concerns about publishing e-mail addresses in any document; therefore, I would say just network names, and the handles/record ids required to lookup records in WHOIS. -- -JH From owen at delong.com Sun Jul 1 23:21:44 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 1 Jul 2012 20:21:44 -0700 Subject: [arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers In-Reply-To: <855077AC3D7A7147A7570370CA01ECD21A7795@SUEX10-mbx-10.ad.syr.edu> References: <20120628030510.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.6d8c08c87a.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD21A7795@SUEX10-mbx-10.ad.syr.edu> Message-ID: <65105109-CFB3-4129-B51D-E11F87F48E1D@delong.com> On Jul 1, 2012, at 4:17 PM, Milton L Mueller wrote: > >> -----Original Message----- >> I understand your desire to sit tight and assess statistical evidence >> before suggesting a longer justification period is required. My concern >> with such a strategy is the decided lack of comprehensive transfer >> market data. We have only the ARIN Specified Transfer Listing Service > > [Milton L Mueller] As a social scientist, it seems obvious to me that asking for statistical support for a longer time frame, without allowing an actual, real-world experiment with the longer time frame, is asking for the impossible. > > The only way to gather "statistical evidence" on the impact of changing the time frame for needs justifications is to allow a different needs assessment time and see how the change affects the quantity and type of transfers authorized. No empirical conclusions can be drawn about the relative merit of a 24-month and 60-month period by looking ONLY at the statistics generated by a 24-month period. And we have now allowed a different policy (24 months instead of 12) and I want to see a statistical analysis of that change before making yet another modification. I'm not sure how you think your argument applies more accurately to 24->60 than it does when I propose it for analyzing the change from 12->24 before applying another change from 24->60. Can you please clarify what I am missing here? > That is why I view the request for statistical evidence as a tactic designed to delay or defeat Jeff's proposal. A very interesting conclusion. Inherently, it would delay Jeff's proposal since we are seeking to wait and see what happens with the last change before applying Jeff's proposed additional change, but, I fail to see how your above statement makes that an unreasonable approach or why delaying Jeff's proposal is somehow an inherently bad thing to do as your statement above seems intended to imply. > If one really wants to do an experiment, it would probably make more sense to conduct a limited experiment with no needs assessment at all, and see what happens. If one discovered a significant increase in the number of approved transactions, and/or a massive increase in what appeared to be speculative acquisitions, and if either result could not be explained by other variables, it would support the conclusion that the current time horizon constricts the number of transactions in a specific way. Other than the magnitude of the consequences, how would this differ from an experiment in cost-cutting prisons where we simply released every prisoner that signed a written promise to obey the law and reversed the policy only after we found many of the criminals breaking the law again? I don't advocate this kind of destructive testing. > In the absence of such an experiment, the only empirical data that might support or refute the change would be a survey of all prospective buyers in which a statistically significant sample of them stated unambiguously that they would participate in the transfer market if the needs period were extended to 60 months; or that their planning horizon for acquiring IP addresses was closer to 5 years than to 2 years. Such a survey would be very difficult to conduct, and you would still be dealing with stated preference rather than revealed preference. But it would be potentially informative. I'm not sure that preference is in question here. I'm sure that those seeking to acquire resources through the transfer market would prefer maximum leniency in the process. I'm willing to accept that as a given. The question at hand is whether allowing that would be damaging to other areas of internet policy and to what extent. Looking at the impact of the switch from 12 to 24 months for some period of time before making yet another modification seems prudent. > The bottom line is that those calling for statistical evidence have one of two choices: either they must agree to conduct an experiment, or they can abandon the claim that they oppose the proposal for lack of statistical evidence and admit that they just don't want it to happen, regardless of evidence. Given sufficient evidence that it would not harm the community to do so, I would not oppose the proposal. Until such evidence becomes available, yes, I oppose the proposal. Whether or not such evidence is or can be made available does not change my desire not to harm the community. As a general rule, it is not unreasonable for the community to expect those desiring a change to bear the burden of proving that the change is more beneficial than harmful to said community. It is my opinion that those supporting this policy have not yet met that burden. Owen From ppml at rs.seastrom.com Mon Jul 2 13:30:43 2012 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 02 Jul 2012 13:30:43 -0400 Subject: [arin-ppml] Transactional transparency In-Reply-To: <855077AC3D7A7147A7570370CA01ECD21A775A@SUEX10-mbx-10.ad.syr.edu> (Milton L. Mueller's message of "Sun, 1 Jul 2012 22:43:08 +0000") References: <855077AC3D7A7147A7570370CA01ECD21A775A@SUEX10-mbx-10.ad.syr.edu> Message-ID: <86y5n2ul30.fsf@seastrom.com> Milton L Mueller writes: > This kind of information is known to facilitate, not disrupt or > prevent, market transactions. Its availability makes the market more > efficient and serves consumer protection purposes as well. Why not a > Zillow for IP addresses? http://www.zillow.com/ > > This ought to be a topic on which all factions can easily > agree. It's just common sense. Zillow is probably the wrong analogy. Why not the equivalent of a NASDAQ Level 2 quote feed? "Market maker" is how I described my vision of the role for the parties that ultimately became known as STLS Facilitators when we were discussing how one might implement paid transfers. -r From mike at nationwideinc.com Mon Jul 2 13:58:36 2012 From: mike at nationwideinc.com (Mike Burns) Date: Mon, 2 Jul 2012 13:58:36 -0400 Subject: [arin-ppml] Transactional transparency In-Reply-To: <86y5n2ul30.fsf@seastrom.com> References: <855077AC3D7A7147A7570370CA01ECD21A775A@SUEX10-mbx-10.ad.syr.edu> <86y5n2ul30.fsf@seastrom.com> Message-ID: <5041FB0D1DBB4C1C87732701D760B27F@MPC> >Zillow is probably the wrong analogy. Why not the equivalent of a NASDAQ Level 2 quote feed? "Market maker" is how I described my vision of the role for the parties that ultimately became known as STLS Facilitators when we were discussing how one might implement paid transfers. >-r Hi Robert, I think a "Market maker" would be able to purchase addresses, but as facilitators we cannot purchase addresses into inventory, no matter how small or ephemerally held. It's hard to make a market without this capability. Regards, Mike Burns From ppml at rs.seastrom.com Tue Jul 3 10:10:31 2012 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Tue, 03 Jul 2012 10:10:31 -0400 Subject: [arin-ppml] Transactional transparency In-Reply-To: <5041FB0D1DBB4C1C87732701D760B27F@MPC> (Mike Burns's message of "Mon, 2 Jul 2012 13:58:36 -0400") References: <855077AC3D7A7147A7570370CA01ECD21A775A@SUEX10-mbx-10.ad.syr.edu> <86y5n2ul30.fsf@seastrom.com> <5041FB0D1DBB4C1C87732701D760B27F@MPC> Message-ID: <86r4st0wbs.fsf@seastrom.com> "Mike Burns" writes: >>Zillow is probably the wrong analogy. Why not the equivalent of a > NASDAQ Level 2 quote feed? "Market maker" is how I described my > vision of the role for the parties that ultimately became known as > STLS Facilitators when we were discussing how one might implement paid > transfers. > >>-r > > Hi Robert, > > I think a "Market maker" would be able to purchase addresses, but as > facilitators we cannot purchase addresses into inventory, no matter > how small or ephemerally held. Hi Mike, That's an excellent fine point on the terminology. Probably "crossing network" would have been a better choice of words - there is still a buy and sell book but the operator of the listing service doesn't actually hold the security. The buy and sell book was what I was focused on; maybe bringing "market maker" into the picture muddied the waters. Sorry if I have been confusing. There are several variations on the theme in securities trading (ATS, ECN, MTF), differing from each other in subtle implementation and regulatory points. Doubtless none of them matches what we're trying to do exactly. > It's hard to make a market without this capability. The goal is liquidity and smooth execution, not necessarily enabling the traditional market maker role. I don't see anything wrong in getting fair compensation for helping to make the deals happen. Thanks for your input and points of refinement; I welcome more. -r From mueller at syr.edu Tue Jul 3 17:44:36 2012 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 3 Jul 2012 21:44:36 +0000 Subject: [arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers In-Reply-To: <65105109-CFB3-4129-B51D-E11F87F48E1D@delong.com> References: <20120628030510.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.6d8c08c87a.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD21A7795@SUEX10-mbx-10.ad.syr.edu> <65105109-CFB3-4129-B51D-E11F87F48E1D@delong.com> Message-ID: <855077AC3D7A7147A7570370CA01ECD21AADE7@SUEX10-mbx-10.ad.syr.edu> Sorry, Owen, I wasn't aware that you were calling for a statistical comparison of the 1 year vs. 2 year, I only saw Jimmy Hess's message, which seemed to be calling for "substantial statistical evidence" favoring 5 years before making a change. It was unclear to me how one could ever get statistical evidence about a 5 year period. How long was 1-year in effect? How long has 2-year been in effect? Based on my rough understanding of the periods, it would seem that increasing the time horizon has already greatly increased the pace and number of transfers. However, there are confounding variables, namely the growing scarcity of IPv4 as time passes and the depletion of the free pool. Regarding the experiment with no needs assessment at all, I guess if you view an experiment with the absence of needs assessment as equivalent to releasing hordes of murderers and rapists into the community unfettered you would indeed be opposed to such an experiment. My point was simply that the difference between a 5 year horizon and no needs assessment at all might be small enough that we needn't bother with a specified time period, if we were actually willing to conduct an "experiment." --MM > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Sunday, July 01, 2012 11:22 PM > To: Milton L Mueller > Cc: jeffmehlenbacher at ipv4marketgroup.com; Scott Leibrand; arin- > ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-176 Increase Needs-Based > Justification to 60 months on 8.3 Specified Transfers > > > On Jul 1, 2012, at 4:17 PM, Milton L Mueller wrote: > > > > >> -----Original Message----- > >> I understand your desire to sit tight and assess statistical evidence > >> before suggesting a longer justification period is required. My > >> concern with such a strategy is the decided lack of comprehensive > >> transfer market data. We have only the ARIN Specified Transfer > >> Listing Service > > > > [Milton L Mueller] As a social scientist, it seems obvious to me that > asking for statistical support for a longer time frame, without allowing > an actual, real-world experiment with the longer time frame, is asking > for the impossible. > > > > The only way to gather "statistical evidence" on the impact of > changing the time frame for needs justifications is to allow a different > needs assessment time and see how the change affects the quantity and > type of transfers authorized. No empirical conclusions can be drawn > about the relative merit of a 24-month and 60-month period by looking > ONLY at the statistics generated by a 24-month period. > > And we have now allowed a different policy (24 months instead of 12) and > I want to see a statistical analysis of that change before making yet > another modification. I'm not sure how you think your argument applies > more accurately to 24->60 than it does when I propose it for analyzing > the change from 12->24 before applying another change from 24->60. Can > you please clarify what I am missing here? > > > That is why I view the request for statistical evidence as a tactic > designed to delay or defeat Jeff's proposal. > > A very interesting conclusion. Inherently, it would delay Jeff's > proposal since we are seeking to wait and see what happens with the last > change before applying Jeff's proposed additional change, but, I fail to > see how your above statement makes that an unreasonable approach or why > delaying Jeff's proposal is somehow an inherently bad thing to do as > your statement above seems intended to imply. > > > If one really wants to do an experiment, it would probably make more > sense to conduct a limited experiment with no needs assessment at all, > and see what happens. If one discovered a significant increase in the > number of approved transactions, and/or a massive increase in what > appeared to be speculative acquisitions, and if either result could not > be explained by other variables, it would support the conclusion that > the current time horizon constricts the number of transactions in a > specific way. > > Other than the magnitude of the consequences, how would this differ from > an experiment in cost-cutting prisons where we simply released every > prisoner that signed a written promise to obey the law and reversed the > policy only after we found many of the criminals breaking the law again? > I don't advocate this kind of destructive testing. > > > In the absence of such an experiment, the only empirical data that > might support or refute the change would be a survey of all prospective > buyers in which a statistically significant sample of them stated > unambiguously that they would participate in the transfer market if the > needs period were extended to 60 months; or that their planning horizon > for acquiring IP addresses was closer to 5 years than to 2 years. Such a > survey would be very difficult to conduct, and you would still be > dealing with stated preference rather than revealed preference. But it > would be potentially informative. > > I'm not sure that preference is in question here. I'm sure that those > seeking to acquire resources through the transfer market would prefer > maximum leniency in the process. I'm willing to accept that as a given. > > The question at hand is whether allowing that would be damaging to other > areas of internet policy and to what extent. Looking at the impact of > the switch from 12 to 24 months for some period of time before making > yet another modification seems prudent. > > > The bottom line is that those calling for statistical evidence have > one of two choices: either they must agree to conduct an experiment, or > they can abandon the claim that they oppose the proposal for lack of > statistical evidence and admit that they just don't want it to happen, > regardless of evidence. > > Given sufficient evidence that it would not harm the community to do so, > I would not oppose the proposal. Until such evidence becomes available, > yes, I oppose the proposal. Whether or not such evidence is or can be > made available does not change my desire not to harm the community. As a > general rule, it is not unreasonable for the community to expect those > desiring a change to bear the burden of proving that the change is more > beneficial than harmful to said community. It is my opinion that those > supporting this policy have not yet met that burden. > > Owen From scottleibrand at gmail.com Tue Jul 3 17:57:29 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 3 Jul 2012 14:57:29 -0700 Subject: [arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers In-Reply-To: <855077AC3D7A7147A7570370CA01ECD21AADE7@SUEX10-mbx-10.ad.syr.edu> References: <20120628030510.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.6d8c08c87a.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD21A7795@SUEX10-mbx-10.ad.syr.edu> <65105109-CFB3-4129-B51D-E11F87F48E1D@delong.com> <855077AC3D7A7147A7570370CA01ECD21AADE7@SUEX10-mbx-10.ad.syr.edu> Message-ID: Another factor I haven't seen discussed is the imminent implementation of the inter-RIR transfer policy. Once that is implemented, I would assume that the scarcity-induced demand from the APNIC region will swamp any remaining time-horizon-certainty demand here in the ARIN region, and we should see a large increase in the number of transfers, most of them to organizations in Asia. I'm not sure whether that is an argument for or against raising the ARIN-region needs basis from 24 months, though. -Scott On Tue, Jul 3, 2012 at 2:44 PM, Milton L Mueller wrote: > Sorry, Owen, > I wasn't aware that you were calling for a statistical comparison of the 1 > year vs. 2 year, I only saw Jimmy Hess's message, which seemed to be > calling for "substantial statistical evidence" favoring 5 years before > making a change. It was unclear to me how one could ever get statistical > evidence about a 5 year period. > > How long was 1-year in effect? How long has 2-year been in effect? Based > on my rough understanding of the periods, it would seem that increasing the > time horizon has already greatly increased the pace and number of > transfers. However, there are confounding variables, namely the growing > scarcity of IPv4 as time passes and the depletion of the free pool. > > Regarding the experiment with no needs assessment at all, I guess if you > view an experiment with the absence of needs assessment as equivalent to > releasing hordes of murderers and rapists into the community unfettered you > would indeed be opposed to such an experiment. My point was simply that the > difference between a 5 year horizon and no needs assessment at all might be > small enough that we needn't bother with a specified time period, if we > were actually willing to conduct an "experiment." > > --MM > > > -----Original Message----- > > From: Owen DeLong [mailto:owen at delong.com] > > Sent: Sunday, July 01, 2012 11:22 PM > > To: Milton L Mueller > > Cc: jeffmehlenbacher at ipv4marketgroup.com; Scott Leibrand; arin- > > ppml at arin.net > > Subject: Re: [arin-ppml] ARIN-prop-176 Increase Needs-Based > > Justification to 60 months on 8.3 Specified Transfers > > > > > > On Jul 1, 2012, at 4:17 PM, Milton L Mueller wrote: > > > > > > > >> -----Original Message----- > > >> I understand your desire to sit tight and assess statistical evidence > > >> before suggesting a longer justification period is required. My > > >> concern with such a strategy is the decided lack of comprehensive > > >> transfer market data. We have only the ARIN Specified Transfer > > >> Listing Service > > > > > > [Milton L Mueller] As a social scientist, it seems obvious to me that > > asking for statistical support for a longer time frame, without allowing > > an actual, real-world experiment with the longer time frame, is asking > > for the impossible. > > > > > > The only way to gather "statistical evidence" on the impact of > > changing the time frame for needs justifications is to allow a different > > needs assessment time and see how the change affects the quantity and > > type of transfers authorized. No empirical conclusions can be drawn > > about the relative merit of a 24-month and 60-month period by looking > > ONLY at the statistics generated by a 24-month period. > > > > And we have now allowed a different policy (24 months instead of 12) and > > I want to see a statistical analysis of that change before making yet > > another modification. I'm not sure how you think your argument applies > > more accurately to 24->60 than it does when I propose it for analyzing > > the change from 12->24 before applying another change from 24->60. Can > > you please clarify what I am missing here? > > > > > That is why I view the request for statistical evidence as a tactic > > designed to delay or defeat Jeff's proposal. > > > > A very interesting conclusion. Inherently, it would delay Jeff's > > proposal since we are seeking to wait and see what happens with the last > > change before applying Jeff's proposed additional change, but, I fail to > > see how your above statement makes that an unreasonable approach or why > > delaying Jeff's proposal is somehow an inherently bad thing to do as > > your statement above seems intended to imply. > > > > > If one really wants to do an experiment, it would probably make more > > sense to conduct a limited experiment with no needs assessment at all, > > and see what happens. If one discovered a significant increase in the > > number of approved transactions, and/or a massive increase in what > > appeared to be speculative acquisitions, and if either result could not > > be explained by other variables, it would support the conclusion that > > the current time horizon constricts the number of transactions in a > > specific way. > > > > Other than the magnitude of the consequences, how would this differ from > > an experiment in cost-cutting prisons where we simply released every > > prisoner that signed a written promise to obey the law and reversed the > > policy only after we found many of the criminals breaking the law again? > > I don't advocate this kind of destructive testing. > > > > > In the absence of such an experiment, the only empirical data that > > might support or refute the change would be a survey of all prospective > > buyers in which a statistically significant sample of them stated > > unambiguously that they would participate in the transfer market if the > > needs period were extended to 60 months; or that their planning horizon > > for acquiring IP addresses was closer to 5 years than to 2 years. Such a > > survey would be very difficult to conduct, and you would still be > > dealing with stated preference rather than revealed preference. But it > > would be potentially informative. > > > > I'm not sure that preference is in question here. I'm sure that those > > seeking to acquire resources through the transfer market would prefer > > maximum leniency in the process. I'm willing to accept that as a given. > > > > The question at hand is whether allowing that would be damaging to other > > areas of internet policy and to what extent. Looking at the impact of > > the switch from 12 to 24 months for some period of time before making > > yet another modification seems prudent. > > > > > The bottom line is that those calling for statistical evidence have > > one of two choices: either they must agree to conduct an experiment, or > > they can abandon the claim that they oppose the proposal for lack of > > statistical evidence and admit that they just don't want it to happen, > > regardless of evidence. > > > > Given sufficient evidence that it would not harm the community to do so, > > I would not oppose the proposal. Until such evidence becomes available, > > yes, I oppose the proposal. Whether or not such evidence is or can be > > made available does not change my desire not to harm the community. As a > > general rule, it is not unreasonable for the community to expect those > > desiring a change to bear the burden of proving that the change is more > > beneficial than harmful to said community. It is my opinion that those > > supporting this policy have not yet met that burden. > > > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Jul 3 20:45:16 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 3 Jul 2012 17:45:16 -0700 Subject: [arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers In-Reply-To: <855077AC3D7A7147A7570370CA01ECD21AADE7@SUEX10-mbx-10.ad.syr.edu> References: <20120628030510.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.6d8c08c87a.wbe@email17.secureserver.net> <855077AC3D7A7147A7570370CA01ECD21A7795@SUEX10-mbx-10.ad.syr.edu> <65105109-CFB3-4129-B51D-E11F87F48E1D@delong.com> <855077AC3D7A7147A7570370CA01ECD21AADE7@SUEX10-mbx-10.ad.syr.edu> Message-ID: <4C8CA198-008C-4675-9CAE-2A6F3851FBDD@delong.com> On Jul 3, 2012, at 2:44 PM, Milton L Mueller wrote: > Sorry, Owen, > I wasn't aware that you were calling for a statistical comparison of the 1 year vs. 2 year, I only saw Jimmy Hess's message, which seemed to be calling for "substantial statistical evidence" favoring 5 years before making a change. It was unclear to me how one could ever get statistical evidence about a 5 year period. > I posted the first call for evidence and suggested that we needed evidence that 5 years would not be harmful before considering such an extreme change. I would also posit that experience with the 2 year period and some evidence that going to 3 years would provide a benefit without causing undue harm is also necessary. > How long was 1-year in effect? How long has 2-year been in effect? Based on my rough understanding of the periods, it would seem that increasing the time horizon has already greatly increased the pace and number of transfers. However, there are confounding variables, namely the growing scarcity of IPv4 as time passes and the depletion of the free pool. One year was in effect as the free-pool allocation period for many years and served us well. It was the original metric for transfers enacted in the 2009-1 draft policy when it was activated, so I would say somewhere between 2 and 3 years. Two years went into effect very recently (the very latest revision of the NRPM). To the best of my knowledge, there have not been any transfers yet since the change, so I'm not sure how you could make such a claim about the increased pace. > Regarding the experiment with no needs assessment at all, I guess if you view an experiment with the absence of needs assessment as equivalent to releasing hordes of murderers and rapists into the community unfettered you would indeed be opposed to such an experiment. My point was simply that the difference between a 5 year horizon and no needs assessment at all might be small enough that we needn't bother with a specified time period, if we were actually willing to conduct an "experiment." I would agree that 5 years bears little difference from eliminating needs basis. The community has resoundingly and repeatedly said no to eliminating needs basis, so I would suggest that on that basis you have just made a very good argument against a 5-year time frame as well. Owen > > --MM > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Sunday, July 01, 2012 11:22 PM >> To: Milton L Mueller >> Cc: jeffmehlenbacher at ipv4marketgroup.com; Scott Leibrand; arin- >> ppml at arin.net >> Subject: Re: [arin-ppml] ARIN-prop-176 Increase Needs-Based >> Justification to 60 months on 8.3 Specified Transfers >> >> >> On Jul 1, 2012, at 4:17 PM, Milton L Mueller wrote: >> >>> >>>> -----Original Message----- >>>> I understand your desire to sit tight and assess statistical evidence >>>> before suggesting a longer justification period is required. My >>>> concern with such a strategy is the decided lack of comprehensive >>>> transfer market data. We have only the ARIN Specified Transfer >>>> Listing Service >>> >>> [Milton L Mueller] As a social scientist, it seems obvious to me that >> asking for statistical support for a longer time frame, without allowing >> an actual, real-world experiment with the longer time frame, is asking >> for the impossible. >>> >>> The only way to gather "statistical evidence" on the impact of >> changing the time frame for needs justifications is to allow a different >> needs assessment time and see how the change affects the quantity and >> type of transfers authorized. No empirical conclusions can be drawn >> about the relative merit of a 24-month and 60-month period by looking >> ONLY at the statistics generated by a 24-month period. >> >> And we have now allowed a different policy (24 months instead of 12) and >> I want to see a statistical analysis of that change before making yet >> another modification. I'm not sure how you think your argument applies >> more accurately to 24->60 than it does when I propose it for analyzing >> the change from 12->24 before applying another change from 24->60. Can >> you please clarify what I am missing here? >> >>> That is why I view the request for statistical evidence as a tactic >> designed to delay or defeat Jeff's proposal. >> >> A very interesting conclusion. Inherently, it would delay Jeff's >> proposal since we are seeking to wait and see what happens with the last >> change before applying Jeff's proposed additional change, but, I fail to >> see how your above statement makes that an unreasonable approach or why >> delaying Jeff's proposal is somehow an inherently bad thing to do as >> your statement above seems intended to imply. >> >>> If one really wants to do an experiment, it would probably make more >> sense to conduct a limited experiment with no needs assessment at all, >> and see what happens. If one discovered a significant increase in the >> number of approved transactions, and/or a massive increase in what >> appeared to be speculative acquisitions, and if either result could not >> be explained by other variables, it would support the conclusion that >> the current time horizon constricts the number of transactions in a >> specific way. >> >> Other than the magnitude of the consequences, how would this differ from >> an experiment in cost-cutting prisons where we simply released every >> prisoner that signed a written promise to obey the law and reversed the >> policy only after we found many of the criminals breaking the law again? >> I don't advocate this kind of destructive testing. >> >>> In the absence of such an experiment, the only empirical data that >> might support or refute the change would be a survey of all prospective >> buyers in which a statistically significant sample of them stated >> unambiguously that they would participate in the transfer market if the >> needs period were extended to 60 months; or that their planning horizon >> for acquiring IP addresses was closer to 5 years than to 2 years. Such a >> survey would be very difficult to conduct, and you would still be >> dealing with stated preference rather than revealed preference. But it >> would be potentially informative. >> >> I'm not sure that preference is in question here. I'm sure that those >> seeking to acquire resources through the transfer market would prefer >> maximum leniency in the process. I'm willing to accept that as a given. >> >> The question at hand is whether allowing that would be damaging to other >> areas of internet policy and to what extent. Looking at the impact of >> the switch from 12 to 24 months for some period of time before making >> yet another modification seems prudent. >> >>> The bottom line is that those calling for statistical evidence have >> one of two choices: either they must agree to conduct an experiment, or >> they can abandon the claim that they oppose the proposal for lack of >> statistical evidence and admit that they just don't want it to happen, >> regardless of evidence. >> >> Given sufficient evidence that it would not harm the community to do so, >> I would not oppose the proposal. Until such evidence becomes available, >> yes, I oppose the proposal. Whether or not such evidence is or can be >> made available does not change my desire not to harm the community. As a >> general rule, it is not unreasonable for the community to expect those >> desiring a change to bear the burden of proving that the change is more >> beneficial than harmful to said community. It is my opinion that those >> supporting this policy have not yet met that burden. >> >> Owen From john.sweeting at twcable.com Thu Jul 5 10:06:48 2012 From: john.sweeting at twcable.com (Sweeting, John) Date: Thu, 5 Jul 2012 10:06:48 -0400 Subject: [arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers In-Reply-To: <20120627111440.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.67d5650a4c.wbe@email17.secureserver.net> Message-ID: Hi Jeff, Sorry for the late notification but I wanted to let you know that Kevin Blumberg has been selected as Primary Shepherd on this proposal. Scott Leibrand will be the secondary. If you have not heard from them by now then you should shortly. I would like to thank you for taking time to participate in the community Policy Development Process and look forward to your continued participation. Thanks, John This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From john.sweeting at twcable.com Thu Jul 5 10:09:26 2012 From: john.sweeting at twcable.com (Sweeting, John) Date: Thu, 5 Jul 2012 10:09:26 -0400 Subject: [arin-ppml] ARIN-prop-177 Revising Section 4.4 C/I Reserved Pool Size In-Reply-To: <4FEB4164.60704@arin.net> Message-ID: All, Just a quick note to let everyone know that Bill Sandiford will be the Primary Shepherd on this proposal. Owen DeLong will be Secondary. Thanks, John On 6/27/12 1:22 PM, "ARIN" wrote: >ARIN-prop-177 Revising Section 4.4 C/I Reserved Pool Size > >ARIN received the following policy proposal and is posting it to the >Public Policy Mailing List (PPML) in accordance with the Policy >Development Process. > >The ARIN Advisory Council (AC) will review the proposal at their next >regularly scheduled meeting (if the period before the next regularly >scheduled meeting is less than 10 days, then the period may be extended >to the subsequent regularly scheduled meeting). The AC will decide how >to utilize the proposal and announce the decision to the PPML. > >The AC invites everyone to comment on the proposal on the PPML, >particularly their support or non-support and the reasoning >behind their opinion. Such participation contributes to a thorough >vetting and provides important guidance to the AC in their deliberations. > >Draft Policies and Proposals under discussion can be found at: >https://www.arin.net/policy/proposals/index.html > >The ARIN Policy Development Process can be found at: >https://www.arin.net/policy/pdp.html > >Mailing list subscription information can be found >at: https://www.arin.net/mailing_lists/ > >Regards, > >Communications and Member Services >American Registry for Internet Numbers (ARIN) > > >## * ## > > >ARIN-prop-177 Revising Section 4.4 C/I Reserved Pool Size > >Proposal Originator: Martin Hannigan > >Proposal Version: 1.0 > >Date: 27 JUNE 2012 > >Proposal type: NEW > >Policy term: PERMANENT > >Policy statement: > >Change Section 4.4 Paragraph 2 from: > >ARIN will place an equivalent of a /16 of IPv4 address space in a >reserve for Critical Infrastructure, as defined in section 4.4. If at >the end of the policy term there is unused address space remaining in >this pool, ARIN staff is authorized to utilize this space in a manner >consistent with community expectations. > >Change Section 4.4 Paragraph 2 to: > >ARIN will place an equivalent of a /15 of IPv4 address space in a >reserve for Critical Infrastructure, as defined in section 4.4. > >Rationale: > >Additional critical infrastructure is being added to the Internet and >in a number greater than anticipated. The original CI pool was created >to serve new IX and new CI requirements. The pending need is estimated >in the 600 new gTLD range. With a /24 assignment from the existing >boundary and the likelihood of some sharing platforms, assigning a /15 >would seem prudent. I also have removed the limited term. If at a >later date we opt to remove or reduce the pool, it's simpler to do so >without an extra step, namely the term. The process for completing the >additions still has some time to play out, but it is likely we will >have exhausted by the time that the process does fully play out. >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jeffmehlenbacher at ipv4marketgroup.com Thu Jul 5 10:12:20 2012 From: jeffmehlenbacher at ipv4marketgroup.com (jeffmehlenbacher at ipv4marketgroup.com) Date: Thu, 05 Jul 2012 07:12:20 -0700 Subject: [arin-ppml] ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers Message-ID: <20120705071220.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.8c58d79e70.wbe@email17.secureserver.net> An HTML attachment was scrubbed... URL: From info at arin.net Thu Jul 5 12:08:43 2012 From: info at arin.net (ARIN) Date: Thu, 05 Jul 2012 12:08:43 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements (Updated Version) Message-ID: <4FF5BC0B.5090801@arin.net> ARIN-prop-173 Revisions to M&A Transfer Requirements The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-173 Revisions to M&A Transfer Requirements Proposal Originator - Marc Lindsey Date - 5 July 2012 Policy type - Modification to existing policy Policy term - Permanent Policy Statement Delete sections 8.1. and 8.2 in their entirety and replace them with the following: 8.1 Principles ARIN will not change its registration databases to record the transfer of number resources between organizations unless such transfer complies with this Section 8. ARIN is tasked with making prudent, fair and expeditious decisions when evaluating registration transfer requests. It should be understood that number resources directly assigned or allocated by ARIN are not 'sold' under ARIN administration. Rather, such number resources are assigned by ARIN to an organization for its exclusive use, provided the terms of the applicable Registration Services Agreement between ARIN and the organization governing use of such number resources continue to be met by such organization. Number resources administered and assigned by ARIN are done so according to ARIN's published policies. ARIN directly assigns and allocated number resources, based on justified need, to organizations, not to individuals representing those organizations. The transfer policies in this Section 8 create certain exceptions and exclusions for legacy numbers ("grandfather policies"). The grandfather policies are intended to satisfy key policy objectives while promoting greater participation in the ARIN community by organizations holding legacy numbers. The grandfather policies allow organizations holding legacy numbers to retain some of the historic benefits attached to their legacy numbers. The benefits of the grandfather policies are not available for legacy numbers if: (a) they are voluntarily and permanently released by the original registrant or its successor (or assign) to an RIR for re-issue to other organizations; where such releases are supported by reliable evidence retained by ARIN or the applicable RIR of the organization's informed and voluntary consent or agreement to permanently release the numbers; or (b) the original registrant or its successor (or assign) of such number enters into an LRSA or RSA expressly referencing the legacy numbers as governed by the terms and conditions of an LRSA or RSA. 8.2. Mergers and Acquisitions When the transfer of any number resource is requested by the current registrant or its successor or assign (the "new entity"), ARIN will transfer the registration of such number resources to the new entity upon receipt of evidence that the new entity has lawfully acquired the number resources from the current registrant as the result of a merger, acquisition, reorganization or name change. ARIN will maintain an up-to-date list of acceptable types of documentation. Transfers under this Section 8.2 shall not be contingent upon the new entity's justification of need for the transferred numbers. 8.2.1 If the transfer request pertains to non-legacy numbers or legacy numbers governed by an LRSA or RSA at the time such transfer request is first submitted to ARIN, the new entity shall be required to execute, in its own name, an RSA covering the transferred numbers, and pay the applicable registration fees. 8.2.2 If the transfer request pertains to legacy numbers that are not, as of the date that the request is first submitted to ARIN, governed expressly by an existing RSA or LRSA, the transfer shall not be contingent upon the new entity entering into or complying with an RSA, LRSA or any other form of written agreement with ARIN. For each transfer of legacy numbers under this Section 8.2.2, ARIN shall assess, and the new entity shall pay, a one-time change charge as set forth in the fee schedule unless the new entity elects, in its discretion, to enter into an LRSA covering the transferred legacy numbers and pays the applicable registration fees. Add the following new definition to Section 2: A "legacy number" means any number resource that meets the following two conditions: (1) the number resource was issued to an entity (other than a Regional Internet Registry) or individual (either, the "original legacy holder") prior to ARIN's inception on Dec 22, 1997 by or through an organization authorized by the United States to issue such number resources; and (2) the original legacy holder (or its legal successor or assign) of such number resource has not voluntarily and permanently released the number to a Regional Internet Registry for subsequent allocation and assignment in accordance with such RIR's number resource policies and membership (or service) agreements. Rationale The current version of 8.2 actually discourages legacy holders from (a) updating the WHOIS database, and (b) paying fees to assist with records management associated with the WHOIS database. Some entities that currently control resources do not attempt to update the WHOIS records because the current transfer process puts at risk their ability to retain and use their numbers. Under the current process, a legacy holder or its lawful successor must first prove that it is the lawful successor (which is necessary and appropriate). But it then must also justify its need to continue using the numbers it obtained prior to ARIN's existence. Once the successor entity passes the needs hurdle, it is required by ARIN to execute an RSA (not an LRSA) as if the numbers were newly allocated from ARIN's free pool. The RSA (and LRSA) substantially alters the rights conveyed to the successor and subjects its numbers to audit and possible revocation under then-current policy. There is, therefore, very little incentive for an M&A successor entity to update the ARIN registry database records. For non-legacy registrants, the process should also be less burdensome and uncertain. Ensuring the continuity of a company's IP addressing scheme as part of an M&A transaction should be within the control of the entities directly involved. ARIN's discretionary approval of transfers in this context introduces an undesirable and unnecessary contingency. Entities concerned about whether their M&A related registration database record update request will be rejected by ARIN simply do not attempt to fully update the records. Minimizing the barriers for both legacy and non-legacy holders to update the WHOIS database when changes are required to accurately reflect normal corporate reorganization activities will help increase the accuracy of the WHOIS database, which benefits the community as a whole. Timetable for implementation - Immediate From owen at delong.com Thu Jul 5 12:50:08 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jul 2012 09:50:08 -0700 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements (Updated Version) In-Reply-To: <4FF5BC0B.5090801@arin.net> References: <4FF5BC0B.5090801@arin.net> Message-ID: Opposed as written. While I support some of the intent of the proposal, here are number of problems with this particular proposal: FIrst, ARIN has no authority or ability to compel exclusivity. All ARIN can provide is a guarantee that the numbers assigned/allocated are unique among cooperating parties. That is, no other RIR nor the IANA nor ARIN will assign/allocate conflicting numbers to another party. Verb tense mixture of assigns and allocated in the last sentence of the second paragraph of proposed 8.1. Creating a policy which is punitive to LRSA signatories is, IMHO, counterproductive. We want to create reasons for legacy registrants to sign LRSAs, not provide additional hurdles to that process. Removal of needs basis from section 8.2 is also not desirable, IMHO. Proposed 8.2.2 should allow the fee to be removed by signing an RSA and not only the LRSA. Defining legacy numbers is in error. There are no such things as legacy numbers. There are legacy registrations, numbers which are subject to a legacy registration, and holders of legacy registrations (aka legacy registrants). Numbers are no longer the subject of a legacy registration once they are covered under an RSA. Registrations for which ARIN provides services without a contract are the legacy registrations of concern in the current policy debates and we should, IMHO, seek to minimize the extent to which such registrations are treated differently, not create additional policy to create additional differences in their treatment. Owen On Jul 5, 2012, at 9:08 AM, ARIN wrote: > ARIN-prop-173 Revisions to M&A Transfer Requirements > > The proposal originator revised the proposal. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-173 Revisions to M&A Transfer Requirements > > Proposal Originator - Marc Lindsey > > Date - 5 July 2012 > > Policy type - Modification to existing policy > > Policy term - Permanent > > Policy Statement > > Delete sections 8.1. and 8.2 in their entirety and replace them with the following: > > 8.1 Principles > > ARIN will not change its registration databases to record the transfer of number resources between organizations unless such transfer complies with this Section 8. ARIN is tasked with making prudent, fair and expeditious decisions when evaluating registration transfer requests. > > It should be understood that number resources directly assigned or allocated by ARIN are not 'sold' under ARIN administration. Rather, such number resources are assigned by ARIN to an organization for its exclusive use, provided the terms of the applicable Registration Services Agreement between ARIN and the organization governing use of such number resources continue to be met by such organization. Number resources administered and assigned by ARIN are done so according to ARIN's published policies. > ARIN directly assigns and allocated number resources, based on justified need, to organizations, not to individuals representing those organizations. > > The transfer policies in this Section 8 create certain exceptions and exclusions for legacy numbers ("grandfather policies"). The grandfather policies are intended to satisfy key policy objectives while promoting greater participation in the ARIN community by organizations holding legacy numbers. The grandfather policies allow organizations holding legacy numbers to retain some of the historic benefits attached to their legacy numbers. > > The benefits of the grandfather policies are not available for legacy numbers if: > > (a) they are voluntarily and permanently released by the original registrant or its successor (or assign) to an RIR for re-issue to other organizations; where such releases are supported by reliable evidence retained by ARIN or the applicable RIR of the organization's informed and voluntary consent or agreement to permanently release the numbers; or > (b) the original registrant or its successor (or assign) of such number enters into an LRSA or RSA expressly referencing the legacy numbers as governed by the terms and conditions of an LRSA or RSA. > > 8.2. Mergers and Acquisitions > > When the transfer of any number resource is requested by the current registrant or its successor or assign (the "new entity"), ARIN will transfer the registration of such number resources to the new entity upon receipt of evidence that the new entity has lawfully acquired the number resources from the current registrant as the result of a merger, acquisition, reorganization or name change. ARIN will maintain an up-to-date list of acceptable types of documentation. Transfers under this Section 8.2 shall not be contingent upon the new entity's justification of need for the transferred numbers. > > 8.2.1 If the transfer request pertains to non-legacy numbers or legacy numbers governed by an LRSA or RSA at the time such transfer request is first submitted to ARIN, the new entity shall be required to execute, in its own name, an RSA covering the transferred numbers, and pay the applicable registration fees. > > 8.2.2 If the transfer request pertains to legacy numbers that are not, as of the date that the request is first submitted to ARIN, governed expressly by an existing RSA or LRSA, the transfer shall not be contingent upon the new entity entering into or complying with an RSA, LRSA or any other form of written agreement with ARIN. > > For each transfer of legacy numbers under this Section 8.2.2, ARIN shall assess, and the new entity shall pay, a one-time change charge as set forth in the fee schedule unless the new entity elects, in its discretion, to enter into an LRSA covering the transferred legacy numbers and pays the applicable registration fees. > > Add the following new definition to Section 2: > > A "legacy number" means any number resource that meets the following two conditions: > > (1) the number resource was issued to an entity (other than a Regional Internet Registry) or individual (either, the "original legacy holder") prior to ARIN's inception on Dec 22, 1997 by or through an organization authorized by the United States to issue such number resources; and > > (2) the original legacy holder (or its legal successor or assign) of such number resource has not voluntarily and permanently released the number to a Regional Internet Registry for subsequent allocation and assignment in accordance with such RIR's number resource policies and membership (or service) agreements. > > Rationale > > The current version of 8.2 actually discourages legacy holders from (a) updating the WHOIS database, and (b) paying fees to assist with records management associated with the WHOIS database. Some entities that currently control resources do not attempt to update the WHOIS records because the current transfer process puts at risk their ability to retain and use their numbers. > > Under the current process, a legacy holder or its lawful successor must first prove that it is the lawful successor (which is necessary and appropriate). But it then must also justify its need to continue using the numbers it obtained prior to ARIN's existence. Once the successor entity passes the needs hurdle, it is required by ARIN to execute an RSA (not an LRSA) as if the numbers were newly allocated from ARIN's free pool. The RSA (and LRSA) substantially alters the rights conveyed to the successor and subjects its numbers to audit and possible revocation under then-current policy. There is, therefore, very little incentive for an M&A successor entity to update the ARIN registry database records. > > For non-legacy registrants, the process should also be less burdensome and uncertain. Ensuring the continuity of a company's IP addressing scheme as part of an M&A transaction should be within the control of the entities directly involved. ARIN's discretionary approval of transfers in this context introduces an undesirable and unnecessary contingency. > > Entities concerned about whether their M&A related registration database record update request will be rejected by ARIN simply do not attempt to fully update the records. > Minimizing the barriers for both legacy and non-legacy holders to update the WHOIS database when changes are required to accurately reflect normal corporate reorganization activities will help increase the accuracy of the WHOIS database, which benefits the community as a whole. > > Timetable for implementation - Immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mike at nationwideinc.com Thu Jul 5 15:17:23 2012 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 5 Jul 2012 15:17:23 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements(Updated Version) In-Reply-To: <4FF5BC0B.5090801@arin.net> References: <4FF5BC0B.5090801@arin.net> Message-ID: <66CB20E7782046B9B2A30135F9766F3E@MPC> 30 of 30 netblocks sold by Nortel had some other entity's name on them in Whois when they were sold to Microsoft. That's evidence of the problem this proposal seeks to rectify. No need for an experiment. Support. Regards, Mike Burns -----Original Message----- From: ARIN Sent: Thursday, July 05, 2012 12:08 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements(Updated Version) ARIN-prop-173 Revisions to M&A Transfer Requirements The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-173 Revisions to M&A Transfer Requirements Proposal Originator - Marc Lindsey Date - 5 July 2012 Policy type - Modification to existing policy Policy term - Permanent Policy Statement Delete sections 8.1. and 8.2 in their entirety and replace them with the following: 8.1 Principles ARIN will not change its registration databases to record the transfer of number resources between organizations unless such transfer complies with this Section 8. ARIN is tasked with making prudent, fair and expeditious decisions when evaluating registration transfer requests. It should be understood that number resources directly assigned or allocated by ARIN are not 'sold' under ARIN administration. Rather, such number resources are assigned by ARIN to an organization for its exclusive use, provided the terms of the applicable Registration Services Agreement between ARIN and the organization governing use of such number resources continue to be met by such organization. Number resources administered and assigned by ARIN are done so according to ARIN's published policies. ARIN directly assigns and allocated number resources, based on justified need, to organizations, not to individuals representing those organizations. The transfer policies in this Section 8 create certain exceptions and exclusions for legacy numbers ("grandfather policies"). The grandfather policies are intended to satisfy key policy objectives while promoting greater participation in the ARIN community by organizations holding legacy numbers. The grandfather policies allow organizations holding legacy numbers to retain some of the historic benefits attached to their legacy numbers. The benefits of the grandfather policies are not available for legacy numbers if: (a) they are voluntarily and permanently released by the original registrant or its successor (or assign) to an RIR for re-issue to other organizations; where such releases are supported by reliable evidence retained by ARIN or the applicable RIR of the organization's informed and voluntary consent or agreement to permanently release the numbers; or (b) the original registrant or its successor (or assign) of such number enters into an LRSA or RSA expressly referencing the legacy numbers as governed by the terms and conditions of an LRSA or RSA. 8.2. Mergers and Acquisitions When the transfer of any number resource is requested by the current registrant or its successor or assign (the "new entity"), ARIN will transfer the registration of such number resources to the new entity upon receipt of evidence that the new entity has lawfully acquired the number resources from the current registrant as the result of a merger, acquisition, reorganization or name change. ARIN will maintain an up-to-date list of acceptable types of documentation. Transfers under this Section 8.2 shall not be contingent upon the new entity's justification of need for the transferred numbers. 8.2.1 If the transfer request pertains to non-legacy numbers or legacy numbers governed by an LRSA or RSA at the time such transfer request is first submitted to ARIN, the new entity shall be required to execute, in its own name, an RSA covering the transferred numbers, and pay the applicable registration fees. 8.2.2 If the transfer request pertains to legacy numbers that are not, as of the date that the request is first submitted to ARIN, governed expressly by an existing RSA or LRSA, the transfer shall not be contingent upon the new entity entering into or complying with an RSA, LRSA or any other form of written agreement with ARIN. For each transfer of legacy numbers under this Section 8.2.2, ARIN shall assess, and the new entity shall pay, a one-time change charge as set forth in the fee schedule unless the new entity elects, in its discretion, to enter into an LRSA covering the transferred legacy numbers and pays the applicable registration fees. Add the following new definition to Section 2: A "legacy number" means any number resource that meets the following two conditions: (1) the number resource was issued to an entity (other than a Regional Internet Registry) or individual (either, the "original legacy holder") prior to ARIN's inception on Dec 22, 1997 by or through an organization authorized by the United States to issue such number resources; and (2) the original legacy holder (or its legal successor or assign) of such number resource has not voluntarily and permanently released the number to a Regional Internet Registry for subsequent allocation and assignment in accordance with such RIR's number resource policies and membership (or service) agreements. Rationale The current version of 8.2 actually discourages legacy holders from (a) updating the WHOIS database, and (b) paying fees to assist with records management associated with the WHOIS database. Some entities that currently control resources do not attempt to update the WHOIS records because the current transfer process puts at risk their ability to retain and use their numbers. Under the current process, a legacy holder or its lawful successor must first prove that it is the lawful successor (which is necessary and appropriate). But it then must also justify its need to continue using the numbers it obtained prior to ARIN's existence. Once the successor entity passes the needs hurdle, it is required by ARIN to execute an RSA (not an LRSA) as if the numbers were newly allocated from ARIN's free pool. The RSA (and LRSA) substantially alters the rights conveyed to the successor and subjects its numbers to audit and possible revocation under then-current policy. There is, therefore, very little incentive for an M&A successor entity to update the ARIN registry database records. For non-legacy registrants, the process should also be less burdensome and uncertain. Ensuring the continuity of a company's IP addressing scheme as part of an M&A transaction should be within the control of the entities directly involved. ARIN's discretionary approval of transfers in this context introduces an undesirable and unnecessary contingency. Entities concerned about whether their M&A related registration database record update request will be rejected by ARIN simply do not attempt to fully update the records. Minimizing the barriers for both legacy and non-legacy holders to update the WHOIS database when changes are required to accurately reflect normal corporate reorganization activities will help increase the accuracy of the WHOIS database, which benefits the community as a whole. Timetable for implementation - Immediate _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From sandrabrown at ipv4marketgroup.com Thu Jul 5 16:31:37 2012 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Thu, 05 Jul 2012 13:31:37 -0700 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) Message-ID: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> from the proposal: >>>>>>>>>>>>>>>> Transfers under this Section 8.2 shall not be contingent upon the new entity's justification of need for the transferred numbers. <<<<<<<<<<<<<<<<<<<<<<< I support Marc Lindsay's proposal. It woud be a significant improvement over the current 8.2. While I was with Nortel, we avoided transferring any legacy blocks that were in the names of Bay Networks, Xylogics, Synoptics, and other past acquisitions, as it made no sense to go through needs assessment as part of that process. Also, as I have posted in the past, I believe the accuracy of the registration database is the most important duty of the ARIN Advisory Council, and this will help the AC to fulfill that duty. Think of the numerous companies that are partially using their blocks, have no intention of monetizing those blocks, and they, under the current 8.2 policy, would have to prove their needs assessment to justify keeping addresses in order to update their registration. At present, I don't think they will come forward, and risk being told to aggregate internally generating tons of engineering and operational work, and thus, the ARIN database would remain out of date. While ARIN often promises to behave reasonably, and has historically tried to make its own rules work, this case would require something secret like a fictitious needs assessment, and I have only heard that to be in Microsoft and Cerner's copies of the ARIN Manual. Mr. Lindsay's proposal will help to overcome this problem. from the proposal: >>>>>>>>>>>>>>>> 8.2.1 If the transfer request pertains to non-legacy numbers or legacy numbers governed by an LRSA or RSA at the time such transfer request is first submitted to ARIN, the new entity shall be required to execute, in its own name, an RSA covering the transferred numbers, and pay the applicable registration fees. <<<<<<<<<<<<<<<<<<<<<<< This new proposal will not totally overcome the problem for those under LRSA. It continues to punish those who have consumed the ARIN koolaid and have mistakenly signed an LRSA. If their ARIN records are incorrect, and they update the transfer information, it will further punish them by converting their LRSA to an RSA. Perhaps that aspect can be fixed in the proposal. As a sidenote, this is a good problem for ARIN to address. We at IPv4 Market Group have many times been asked by companies contemplating sales of IPv4 assets if they should first do an 8.2 transfer and we have to tell them no, due to the punitive wording of 8.2. They are much better off to leave their registrations incorrect until they can arrange a sale, and this is not in the best interest of an accurate Internet. Sandra Brown, speaking both as myself, and on behalf of IPv4 Market Group From jcurran at arin.net Thu Jul 5 16:43:55 2012 From: jcurran at arin.net (John Curran) Date: Thu, 5 Jul 2012 20:43:55 +0000 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> Message-ID: <33D9419C-CD16-4287-8663-60221DDDF6A5@corp.arin.net> On Jul 5, 2012, at 4:31 PM, sandrabrown at ipv4marketgroup.com wrote: > I support Marc Lindsay's proposal. It woud be a significant improvement > over the current 8.2. While I was with Nortel, we avoided transferring > any legacy blocks that were in the names of Bay Networks, Xylogics, > Synoptics, and other past acquisitions, as it made no sense to go > through needs assessment as part of that process. > > Also, as I have posted in the past, I believe the accuracy of the > registration database is the most important duty of the ARIN Advisory > Council, and this will help the AC to fulfill that duty. > > Think of the numerous companies that are partially using their blocks, > have no intention of monetizing those blocks, and they, under the > current 8.2 policy, would have to prove their needs assessment to > justify keeping addresses in order to update their registration. > > At present, I don't think they will come forward, and risk being told to > aggregate internally generating tons of engineering and operational > work, and thus, the ARIN database would remain out of date. While ARIN > often promises to behave reasonably, and has historically tried to make > its own rules work, this case would require something secret like a > fictitious needs assessment, and I have only heard that to be in > Microsoft and Cerner's copies of the ARIN Manual. I have no view on the benefits or risks of the policy proposal in question, but will note for the record that all transfer that have been completed to date have been in compliance with policy, including necessary needs-assessment. If you are aware of any case with number resources being transferred contrary to adopted policy, please report it via the ARIN number resource fraud reporting form which is available here: https://www.arin.net/resources/fraud/index.html Thanks! /John John Curran President and CEO ARIN From dogwallah at gmail.com Thu Jul 5 17:25:05 2012 From: dogwallah at gmail.com (McTim) Date: Thu, 5 Jul 2012 17:25:05 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> Message-ID: Hi, On Thu, Jul 5, 2012 at 4:31 PM, wrote: > > from the proposal: >>>>>>>>>>>>>>>>> > Transfers under > this Section 8.2 shall not be contingent upon the new entity's > justification of need for the transferred numbers. > > <<<<<<<<<<<<<<<<<<<<<<< > > > I support Marc Lindsay's proposal. ?It woud be a significant improvement > over the current 8.2. ?While I was with Nortel, we avoided transferring > any legacy blocks that were in the names of Bay Networks, Xylogics, > Synoptics, and other past acquisitions, as it made no sense to go > through needs assessment as part of that process. > > Also, as I have posted in the past, I believe the accuracy of the > registration database is the most important duty of the ARIN Advisory > Council, and this will help the AC to fulfill that duty. > Responsibilities of the AC are listed here: https://www.arin.net/about_us/ac_requirements.html I'm not sure I would put accuracy of WHOIS data on their plate as well, the list is long enough I would think. > Think of the numerous companies that are partially using their blocks, > have no intention of monetizing those blocks, and they, under the > current 8.2 policy, would have to prove their needs assessment to > justify keeping addresses in order to update their registration. this seems to be a trivial requirement to me...YMMV. > > At present, I don't think they will come forward, and risk being told to > aggregate internally generating tons of engineering and operational > work, Do RIRs tell folk how to number their network? I think this is a red-herring. and thus, the ARIN database would remain out of date. ?While ARIN > often promises to behave reasonably, and has historically tried to make > its own rules work, this case would require something secret like a > fictitious needs assessment, and I have only heard that to be in > Microsoft and Cerner's copies of the ARIN Manual. > What case are you referring to above? > Mr. Lindsay's proposal will help to overcome this problem. > > > from the proposal: >>>>>>>>>>>>>>>>> > 8.2.1 If the transfer request pertains to non-legacy numbers or legacy > numbers governed by an LRSA or RSA at the time such transfer request is > first submitted to ARIN, the new entity shall be required to execute, in > > its own name, an RSA covering the transferred numbers, and pay the > applicable registration fees. > <<<<<<<<<<<<<<<<<<<<<<< > > This new proposal will not totally overcome the problem for those under > LRSA. ?It continues to punish those how so? who have consumed the ARIN koolaid > and have mistakenly signed an LRSA. ?If their ARIN records are > incorrect, and they update the transfer information, it will further > punish them by converting their LRSA to an RSA. ?Perhaps that aspect can > be fixed in the proposal. > > As a sidenote, this is a good problem for ARIN to address. ?We at IPv4 > Market Group have many times been asked by companies contemplating sales > of IPv4 assets if they should first do an 8.2 transfer and we have to > tell them no, due to the punitive wording of 8.2. ?They are much better > off to leave their registrations incorrect until they can arrange a > sale, and this is not in the best interest of an accurate Internet. So now we see the heart of the matter. Your concern over the accuracy of WHOIS data takes a back seat to profit via the sale of v4 resources (and your commission presumably). 8.1 and 8.2 are, at the moment clauses I can grok at first reading. I can't say the same for this proposal. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From farmer at umn.edu Thu Jul 5 17:43:02 2012 From: farmer at umn.edu (David Farmer) Date: Thu, 05 Jul 2012 16:43:02 -0500 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements (Updated Version) In-Reply-To: <4FF5BC0B.5090801@arin.net> References: <4FF5BC0B.5090801@arin.net> Message-ID: <4FF60A66.8000708@umn.edu> I do not support this policy as written. However, I do support removing needs justification for all M&A transfers. I believe this can be simplified significantly, the legacy resource language is not necessary and can be eliminated. All M&A transfers should not be required to demonstrate need as long as the transfer in question is a name or organization structure change, or a merger or acquisition were the number resources are transferred with all other assets or with a substantial portion of the assets an organization, especially including the equipment that utilizes the number resources in question. If the number resources are the sole asset or the only substantial asset being transferred then an 8.3 transfer with needs justification should be required. I don't not believe it is necessary to make a distinction between legacy and non-legacy resources to accomplish the intended result of removing needs justification for M&A transfers. I do agree that needs justification on M&A transfers creates a significant disincentive for legacy resources holders to keep the registry properly updated. But the policy change shouldn't be specific to legacy resources or resource holders, it should apply equally to all resources and resource holders. On 7/5/12 11:08 CDT, ARIN wrote: > ARIN-prop-173 Revisions to M&A Transfer Requirements > > The proposal originator revised the proposal. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-173 Revisions to M&A Transfer Requirements > > Proposal Originator - Marc Lindsey > > Date - 5 July 2012 > > Policy type - Modification to existing policy > > Policy term - Permanent > > Policy Statement > > Delete sections 8.1. and 8.2 in their entirety and replace them with the > following: > > 8.1 Principles > > ARIN will not change its registration databases to record the transfer > of number resources between organizations unless such transfer complies > with this Section 8. ARIN is tasked with making prudent, fair and > expeditious decisions when evaluating registration transfer requests. > > It should be understood that number resources directly assigned or > allocated by ARIN are not 'sold' under ARIN administration. Rather, such > number resources are assigned by ARIN to an organization for its > exclusive use, provided the terms of the applicable Registration > Services Agreement between ARIN and the organization governing use of > such number resources continue to be met by such organization. Number > resources administered and assigned by ARIN are done so according to > ARIN's published policies. > ARIN directly assigns and allocated number resources, based on justified > need, to organizations, not to individuals representing those > organizations. > > The transfer policies in this Section 8 create certain exceptions and > exclusions for legacy numbers ("grandfather policies"). The grandfather > policies are intended to satisfy key policy objectives while promoting > greater participation in the ARIN community by organizations holding > legacy numbers. The grandfather policies allow organizations holding > legacy numbers to retain some of the historic benefits attached to their > legacy numbers. > > The benefits of the grandfather policies are not available for legacy > numbers if: > > (a) they are voluntarily and permanently released by the original > registrant or its successor (or assign) to an RIR for re-issue to other > organizations; where such releases are supported by reliable evidence > retained by ARIN or the applicable RIR of the organization's informed > and voluntary consent or agreement to permanently release the numbers; or > (b) the original registrant or its successor (or assign) of such number > enters into an LRSA or RSA expressly referencing the legacy numbers as > governed by the terms and conditions of an LRSA or RSA. > > 8.2. Mergers and Acquisitions > > When the transfer of any number resource is requested by the current > registrant or its successor or assign (the "new entity"), ARIN will > transfer the registration of such number resources to the new entity > upon receipt of evidence that the new entity has lawfully acquired the > number resources from the current registrant as the result of a merger, > acquisition, reorganization or name change. ARIN will maintain an > up-to-date list of acceptable types of documentation. Transfers under > this Section 8.2 shall not be contingent upon the new entity's > justification of need for the transferred numbers. > > 8.2.1 If the transfer request pertains to non-legacy numbers or legacy > numbers governed by an LRSA or RSA at the time such transfer request is > first submitted to ARIN, the new entity shall be required to execute, in > its own name, an RSA covering the transferred numbers, and pay the > applicable registration fees. > > 8.2.2 If the transfer request pertains to legacy numbers that are not, > as of the date that the request is first submitted to ARIN, governed > expressly by an existing RSA or LRSA, the transfer shall not be > contingent upon the new entity entering into or complying with an RSA, > LRSA or any other form of written agreement with ARIN. > > For each transfer of legacy numbers under this Section 8.2.2, ARIN shall > assess, and the new entity shall pay, a one-time change charge as set > forth in the fee schedule unless the new entity elects, in its > discretion, to enter into an LRSA covering the transferred legacy > numbers and pays the applicable registration fees. > > Add the following new definition to Section 2: > > A "legacy number" means any number resource that meets the following two > conditions: > > (1) the number resource was issued to an entity (other than a Regional > Internet Registry) or individual (either, the "original legacy holder") > prior to ARIN's inception on Dec 22, 1997 by or through an organization > authorized by the United States to issue such number resources; and > > (2) the original legacy holder (or its legal successor or assign) of > such number resource has not voluntarily and permanently released the > number to a Regional Internet Registry for subsequent allocation and > assignment in accordance with such RIR's number resource policies and > membership (or service) agreements. > > Rationale > > The current version of 8.2 actually discourages legacy holders from (a) > updating the WHOIS database, and (b) paying fees to assist with records > management associated with the WHOIS database. Some entities that > currently control resources do not attempt to update the WHOIS records > because the current transfer process puts at risk their ability to > retain and use their numbers. > > Under the current process, a legacy holder or its lawful successor must > first prove that it is the lawful successor (which is necessary and > appropriate). But it then must also justify its need to continue using > the numbers it obtained prior to ARIN's existence. Once the successor > entity passes the needs hurdle, it is required by ARIN to execute an RSA > (not an LRSA) as if the numbers were newly allocated from ARIN's free > pool. The RSA (and LRSA) substantially alters the rights conveyed to > the successor and subjects its numbers to audit and possible revocation > under then-current policy. There is, therefore, very little incentive > for an M&A successor entity to update the ARIN registry database records. > > For non-legacy registrants, the process should also be less burdensome > and uncertain. Ensuring the continuity of a company's IP addressing > scheme as part of an M&A transaction should be within the control of the > entities directly involved. ARIN's discretionary approval of transfers > in this context introduces an undesirable and unnecessary contingency. > > Entities concerned about whether their M&A related registration database > record update request will be rejected by ARIN simply do not attempt to > fully update the records. > Minimizing the barriers for both legacy and non-legacy holders to update > the WHOIS database when changes are required to accurately reflect > normal corporate reorganization activities will help increase the > accuracy of the WHOIS database, which benefits the community as a whole. > > Timetable for implementation - Immediate -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From lee at dilkie.com Thu Jul 5 18:04:06 2012 From: lee at dilkie.com (Lee Dilkie) Date: Thu, 05 Jul 2012 18:04:06 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements (Updated Version) In-Reply-To: <4FF60A66.8000708@umn.edu> References: <4FF5BC0B.5090801@arin.net> <4FF60A66.8000708@umn.edu> Message-ID: <4FF60F56.9080105@dilkie.com> agreed. On 7/5/2012 5:43 PM, David Farmer wrote: > I do not support this policy as written. > > However, I do support removing needs justification for all M&A transfers. > > I believe this can be simplified significantly, the legacy resource > language is not necessary and can be eliminated. All M&A transfers > should not be required to demonstrate need as long as the transfer in > question is a name or organization structure change, or a merger or > acquisition were the number resources are transferred with all other > assets or with a substantial portion of the assets an organization, > especially including the equipment that utilizes the number resources > in question. If the number resources are the sole asset or the only > substantial asset being transferred then an 8.3 transfer with needs > justification should be required. > > I don't not believe it is necessary to make a distinction between > legacy and non-legacy resources to accomplish the intended result of > removing needs justification for M&A transfers. > > I do agree that needs justification on M&A transfers creates a > significant disincentive for legacy resources holders to keep the > registry properly updated. But the policy change shouldn't be > specific to legacy resources or resource holders, it should apply > equally to all resources and resource holders. > > On 7/5/12 11:08 CDT, ARIN wrote: >> ARIN-prop-173 Revisions to M&A Transfer Requirements >> >> The proposal originator revised the proposal. >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> ARIN-prop-173 Revisions to M&A Transfer Requirements >> >> Proposal Originator - Marc Lindsey >> >> Date - 5 July 2012 >> >> Policy type - Modification to existing policy >> >> Policy term - Permanent >> >> Policy Statement >> >> Delete sections 8.1. and 8.2 in their entirety and replace them with the >> following: >> >> 8.1 Principles >> >> ARIN will not change its registration databases to record the transfer >> of number resources between organizations unless such transfer complies >> with this Section 8. ARIN is tasked with making prudent, fair and >> expeditious decisions when evaluating registration transfer requests. >> >> It should be understood that number resources directly assigned or >> allocated by ARIN are not 'sold' under ARIN administration. Rather, such >> number resources are assigned by ARIN to an organization for its >> exclusive use, provided the terms of the applicable Registration >> Services Agreement between ARIN and the organization governing use of >> such number resources continue to be met by such organization. Number >> resources administered and assigned by ARIN are done so according to >> ARIN's published policies. >> ARIN directly assigns and allocated number resources, based on justified >> need, to organizations, not to individuals representing those >> organizations. >> >> The transfer policies in this Section 8 create certain exceptions and >> exclusions for legacy numbers ("grandfather policies"). The grandfather >> policies are intended to satisfy key policy objectives while promoting >> greater participation in the ARIN community by organizations holding >> legacy numbers. The grandfather policies allow organizations holding >> legacy numbers to retain some of the historic benefits attached to their >> legacy numbers. >> >> The benefits of the grandfather policies are not available for legacy >> numbers if: >> >> (a) they are voluntarily and permanently released by the original >> registrant or its successor (or assign) to an RIR for re-issue to other >> organizations; where such releases are supported by reliable evidence >> retained by ARIN or the applicable RIR of the organization's informed >> and voluntary consent or agreement to permanently release the >> numbers; or >> (b) the original registrant or its successor (or assign) of such number >> enters into an LRSA or RSA expressly referencing the legacy numbers as >> governed by the terms and conditions of an LRSA or RSA. >> >> 8.2. Mergers and Acquisitions >> >> When the transfer of any number resource is requested by the current >> registrant or its successor or assign (the "new entity"), ARIN will >> transfer the registration of such number resources to the new entity >> upon receipt of evidence that the new entity has lawfully acquired the >> number resources from the current registrant as the result of a merger, >> acquisition, reorganization or name change. ARIN will maintain an >> up-to-date list of acceptable types of documentation. Transfers under >> this Section 8.2 shall not be contingent upon the new entity's >> justification of need for the transferred numbers. >> >> 8.2.1 If the transfer request pertains to non-legacy numbers or legacy >> numbers governed by an LRSA or RSA at the time such transfer request is >> first submitted to ARIN, the new entity shall be required to execute, in >> its own name, an RSA covering the transferred numbers, and pay the >> applicable registration fees. >> >> 8.2.2 If the transfer request pertains to legacy numbers that are not, >> as of the date that the request is first submitted to ARIN, governed >> expressly by an existing RSA or LRSA, the transfer shall not be >> contingent upon the new entity entering into or complying with an RSA, >> LRSA or any other form of written agreement with ARIN. >> >> For each transfer of legacy numbers under this Section 8.2.2, ARIN shall >> assess, and the new entity shall pay, a one-time change charge as set >> forth in the fee schedule unless the new entity elects, in its >> discretion, to enter into an LRSA covering the transferred legacy >> numbers and pays the applicable registration fees. >> >> Add the following new definition to Section 2: >> >> A "legacy number" means any number resource that meets the following two >> conditions: >> >> (1) the number resource was issued to an entity (other than a Regional >> Internet Registry) or individual (either, the "original legacy holder") >> prior to ARIN's inception on Dec 22, 1997 by or through an organization >> authorized by the United States to issue such number resources; and >> >> (2) the original legacy holder (or its legal successor or assign) of >> such number resource has not voluntarily and permanently released the >> number to a Regional Internet Registry for subsequent allocation and >> assignment in accordance with such RIR's number resource policies and >> membership (or service) agreements. >> >> Rationale >> >> The current version of 8.2 actually discourages legacy holders from (a) >> updating the WHOIS database, and (b) paying fees to assist with records >> management associated with the WHOIS database. Some entities that >> currently control resources do not attempt to update the WHOIS records >> because the current transfer process puts at risk their ability to >> retain and use their numbers. >> >> Under the current process, a legacy holder or its lawful successor must >> first prove that it is the lawful successor (which is necessary and >> appropriate). But it then must also justify its need to continue using >> the numbers it obtained prior to ARIN's existence. Once the successor >> entity passes the needs hurdle, it is required by ARIN to execute an RSA >> (not an LRSA) as if the numbers were newly allocated from ARIN's free >> pool. The RSA (and LRSA) substantially alters the rights conveyed to >> the successor and subjects its numbers to audit and possible revocation >> under then-current policy. There is, therefore, very little incentive >> for an M&A successor entity to update the ARIN registry database >> records. >> >> For non-legacy registrants, the process should also be less burdensome >> and uncertain. Ensuring the continuity of a company's IP addressing >> scheme as part of an M&A transaction should be within the control of the >> entities directly involved. ARIN's discretionary approval of transfers >> in this context introduces an undesirable and unnecessary contingency. >> >> Entities concerned about whether their M&A related registration database >> record update request will be rejected by ARIN simply do not attempt to >> fully update the records. >> Minimizing the barriers for both legacy and non-legacy holders to update >> the WHOIS database when changes are required to accurately reflect >> normal corporate reorganization activities will help increase the >> accuracy of the WHOIS database, which benefits the community as a whole. >> >> Timetable for implementation - Immediate > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael+ppml at burnttofu.net Thu Jul 5 18:17:14 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Thu, 05 Jul 2012 15:17:14 -0700 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> Message-ID: <4FF6126A.8020503@burnttofu.net> On 07/05/12 13:31, sandrabrown at ipv4marketgroup.com wrote: > At present, I don't think they will come forward, and risk being told to > aggregate internally generating tons of engineering and operational > work, and thus, the ARIN database would remain out of date. To the extent that this proposal exempts M&A transfers from any renumbering requirement (or even encouragement), it introduces a double-standard into the NRPM. As an example, section 4.3.6.2 requires small multihomers (I love that word!) to renumber upon getting additional assignments. Note the opposition on this mailing list to proposal 167, which would have mitigated that requirement. While not expressing an opinion as to who should "have to" renumber, I do not think the NRPM should have the effect, intended or otherwise, of placing greater renumbering onus on small entities versus large ones. If we're concerned about routing table bloat from the mom-and-pops, then we should be concerned about it from M&A transfers, regardless of the size of the merger or acquisition. Likewise, if it was "too hard" for a Nortel to consider renumbering, why is it so much easier for a mom-and-pop to renumber? Mom-and-pops don't have to renumber as much, but they don't have the same resources at their disposal to throw at the renumbering task. michael From farmer at umn.edu Thu Jul 5 18:24:25 2012 From: farmer at umn.edu (David Farmer) Date: Thu, 05 Jul 2012 17:24:25 -0500 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <4FF6126A.8020503@burnttofu.net> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> Message-ID: <4FF61419.1030302@umn.edu> On 7/5/12 17:17 CDT, Michael Sinatra wrote: > On 07/05/12 13:31, sandrabrown at ipv4marketgroup.com wrote: > >> At present, I don't think they will come forward, and risk being told to >> aggregate internally generating tons of engineering and operational >> work, and thus, the ARIN database would remain out of date. > > To the extent that this proposal exempts M&A transfers from any > renumbering requirement (or even encouragement), it introduces a > double-standard into the NRPM. As an example, section 4.3.6.2 requires > small multihomers (I love that word!) to renumber upon getting > additional assignments. Note the opposition on this mailing list to > proposal 167, which would have mitigated that requirement. While not > expressing an opinion as to who should "have to" renumber, I do not > think the NRPM should have the effect, intended or otherwise, of placing > greater renumbering onus on small entities versus large ones. If we're > concerned about routing table bloat from the mom-and-pops, then we > should be concerned about it from M&A transfers, regardless of the size > of the merger or acquisition. Likewise, if it was "too hard" for a > Nortel to consider renumbering, why is it so much easier for a > mom-and-pop to renumber? Mom-and-pops don't have to renumber as much, > but they don't have the same resources at their disposal to throw at the > renumbering task. I'm missing something here, how does renumbering apply to this discussion? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From michael+ppml at burnttofu.net Thu Jul 5 18:28:17 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Thu, 05 Jul 2012 15:28:17 -0700 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <4FF61419.1030302@umn.edu> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> <4FF61419.1030302@umn.edu> Message-ID: <4FF61501.9040707@burnttofu.net> On 07/05/12 15:24, David Farmer wrote: > > > On 7/5/12 17:17 CDT, Michael Sinatra wrote: >> On 07/05/12 13:31, sandrabrown at ipv4marketgroup.com wrote: >> >>> At present, I don't think they will come forward, and risk being told to >>> aggregate internally generating tons of engineering and operational >>> work, and thus, the ARIN database would remain out of date. >> >> To the extent that this proposal exempts M&A transfers from any >> renumbering requirement (or even encouragement), it introduces a >> double-standard into the NRPM. As an example, section 4.3.6.2 requires >> small multihomers (I love that word!) to renumber upon getting >> additional assignments. Note the opposition on this mailing list to >> proposal 167, which would have mitigated that requirement. While not >> expressing an opinion as to who should "have to" renumber, I do not >> think the NRPM should have the effect, intended or otherwise, of placing >> greater renumbering onus on small entities versus large ones. If we're >> concerned about routing table bloat from the mom-and-pops, then we >> should be concerned about it from M&A transfers, regardless of the size >> of the merger or acquisition. Likewise, if it was "too hard" for a >> Nortel to consider renumbering, why is it so much easier for a >> mom-and-pop to renumber? Mom-and-pops don't have to renumber as much, >> but they don't have the same resources at their disposal to throw at the >> renumbering task. > > I'm missing something here, how does renumbering apply to this discussion? Paragraph 2 of section 8.2: "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, *aggregate,* transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy." Sandra appeared to be responding to the possibility that ARIN would request that M&A transfers result in the aggregation (i.e. renumbering) of resources, which she considers onerous: "isk being told to aggregate internally generating tons of engineering and operational work." michael From farmer at umn.edu Thu Jul 5 19:05:47 2012 From: farmer at umn.edu (David Farmer) Date: Thu, 05 Jul 2012 18:05:47 -0500 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <4FF61501.9040707@burnttofu.net> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> <4FF61419.1030302@umn.edu> <4FF61501.9040707@burnttofu.net> Message-ID: <4FF61DCB.8090100@umn.edu> On 7/5/12 17:28 CDT, Michael Sinatra wrote: > On 07/05/12 15:24, David Farmer wrote: >> >> >> On 7/5/12 17:17 CDT, Michael Sinatra wrote: >>> On 07/05/12 13:31, sandrabrown at ipv4marketgroup.com wrote: >>> >>>> At present, I don't think they will come forward, and risk being >>>> told to >>>> aggregate internally generating tons of engineering and operational >>>> work, and thus, the ARIN database would remain out of date. >>> >>> To the extent that this proposal exempts M&A transfers from any >>> renumbering requirement (or even encouragement), it introduces a >>> double-standard into the NRPM. As an example, section 4.3.6.2 requires >>> small multihomers (I love that word!) to renumber upon getting >>> additional assignments. Note the opposition on this mailing list to >>> proposal 167, which would have mitigated that requirement. While not >>> expressing an opinion as to who should "have to" renumber, I do not >>> think the NRPM should have the effect, intended or otherwise, of placing >>> greater renumbering onus on small entities versus large ones. If we're >>> concerned about routing table bloat from the mom-and-pops, then we >>> should be concerned about it from M&A transfers, regardless of the size >>> of the merger or acquisition. Likewise, if it was "too hard" for a >>> Nortel to consider renumbering, why is it so much easier for a >>> mom-and-pop to renumber? Mom-and-pops don't have to renumber as much, >>> but they don't have the same resources at their disposal to throw at the >>> renumbering task. >> >> I'm missing something here, how does renumbering apply to this >> discussion? > > Paragraph 2 of section 8.2: > > "In the event that number resources of the combined organizations are no > longer justified under ARIN policy at the time ARIN becomes aware of the > transaction, through a transfer request or otherwise, ARIN will work > with the resource holder(s) to return, *aggregate,* transfer, or reclaim > resources as needed to restore compliance via the processes outlined in > current ARIN policy." > > Sandra appeared to be responding to the possibility that ARIN would > request that M&A transfers result in the aggregation (i.e. renumbering) > of resources, which she considers onerous: "isk being told to aggregate > internally generating tons of engineering and operational work." OK, I agree that it shouldn't matter how big you are If you need to aggregate or renumber you need to do it. However, big or small, legacy or not, why should you have to aggregate and return addresses because you change the name of the organization? Why should that event trigger that? If a mom and pop organization changes its name they should be able to update the records with the new name without having to rejustify their use, its not about size. If they we justified under the old name why shouldn't they be justified under the new name? The use didn't change by changing the name. If you are changing the use by transferring the number resource independently then yes you need to rejustify the use, that is what 8.3 is about. But, why for a name change, that seems like a high bar for something that trivial. I don't agree with most of the rest what she said, but on this issue I agree It creates a disincentive for updating the registry. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Thu Jul 5 19:23:02 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jul 2012 16:23:02 -0700 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <4FF61DCB.8090100@umn.edu> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> <4FF61419.1030302@umn.edu> <4FF61501.9040707@burnttofu.net> <4FF61DCB.8090100@umn.edu> Message-ID: <4F806A19-842D-44C6-8ACD-D4306EC8EFF6@delong.com> >> > > OK, > > I agree that it shouldn't matter how big you are If you need to aggregate or renumber you need to do it. However, big or small, legacy or not, why should you have to aggregate and return addresses because you change the name of the organization? Why should that event trigger that? > 8.2 covers a lot more than just an organizational name change. If you have a company that was holding a /16 and had usage which just barely justified that /16 and they merge with a company holding a /9 which has more than a /14 of free space (which is still 80% utilization), then there is no reason that the /16 should not be renumbered into the /9 and reclaimed. I support giving an extended period to accomplish the renumbering, but I do not support removing needs basis. > If a mom and pop organization changes its name they should be able to update the records with the new name without having to rejustify their use, its not about size. If they we justified under the old name why shouldn't they be justified under the new name? The use didn't change by changing the name. You are assuming that 8.2 only covers name changes. It does not. In fact, as I understand it, a name change does not require an 8.2 or 8.3 transfer if you can show that the new name and the old name are the same entity and not an ownership change. > If you are changing the use by transferring the number resource independently then yes you need to rejustify the use, that is what 8.3 is about. But, why for a name change, that seems like a high bar for something that trivial. There are other ways to change use or change the dynamics of the use which often occur around mergers and acquisitions. > I don't agree with most of the rest what she said, but on this issue I agree It creates a disincentive for updating the registry. It creates some disincentive to update the registry, but, there are many areas where having inconvenient policy creates a disincentive to conform to policy. I do not buy that as a reason to eliminate the policy in and of itself. Owen From narten at us.ibm.com Fri Jul 6 00:53:03 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 06 Jul 2012 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201207060453.q664r3hR002268@rotala.raleigh.ibm.com> Total of 73 messages in the last 7 days. script run at: Fri Jul 6 00:53:03 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 1.37% | 1 | 80.02% | 2756103 | sryerse at eclipse-networks.com 19.18% | 14 | 4.69% | 161412 | owen at delong.com 12.33% | 9 | 1.95% | 67204 | jcurran at arin.net 10.96% | 8 | 1.81% | 62481 | mysidia at gmail.com 8.22% | 6 | 1.79% | 61589 | farmer at umn.edu 8.22% | 6 | 1.59% | 54750 | mueller at syr.edu 6.85% | 5 | 1.55% | 53414 | jeffmehlenbacher at ipv4marketgroup.com 6.85% | 5 | 0.97% | 33262 | bill at herrin.us 2.74% | 2 | 0.51% | 17570 | mike at nationwideinc.com 2.74% | 2 | 0.44% | 15104 | dogwallah at gmail.com 2.74% | 2 | 0.43% | 14844 | john.sweeting at twcable.com 2.74% | 2 | 0.39% | 13346 | michael+ppml at burnttofu.net 2.74% | 2 | 0.33% | 11204 | ppml at rs.seastrom.com 1.37% | 1 | 0.77% | 26383 | lee at dilkie.com 1.37% | 1 | 0.66% | 22756 | scottleibrand at gmail.com 1.37% | 1 | 0.57% | 19529 | tvest at eyeconomics.com 1.37% | 1 | 0.44% | 15213 | avri at acm.org 1.37% | 1 | 0.32% | 11105 | info at arin.net 1.37% | 1 | 0.22% | 7510 | sandrabrown at ipv4marketgroup.com 1.37% | 1 | 0.22% | 7484 | narten at us.ibm.com 1.37% | 1 | 0.18% | 6138 | hannigan at gmail.com 1.37% | 1 | 0.18% | 6032 | woody at pch.net --------+------+--------+----------+------------------------ 100.00% | 73 |100.00% | 3444433 | Total From mlindsey at lb3law.com Fri Jul 6 01:58:43 2012 From: mlindsey at lb3law.com (Lindsey, Marc) Date: Fri, 6 Jul 2012 01:58:43 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements Message-ID: <98E8C412B2F47D48A79816422B860E1B04B9EC926E6F@lb3ex01> Owen, Thanks for your (as always) prompt, and less critical-than-expected response. It almost sounds like you could be in favor of the proposal with some further revision. See some additional comments below. . . . . Owen wrote: FIrst, ARIN has no authority or ability to compel exclusivity. All ARIN can provide is a guarantee that the numbers assigned/allocated are unique among cooperating parties. That is, no other RIR nor the IANA nor ARIN will assign/allocate conflicting numbers to another party. <<< Marc Lindsey Reply >>> I think I agree with you, but I'm not sure. Is there something in my proposal that suggests that I believe ARIN has the power to compel non-members to do or not do something? . . . . Owen wrote: Creating a policy which is punitive to LRSA signatories is, IMHO, counterproductive. We want to create reasons for legacy registrants to sign LRSAs, not provide additional hurdles to that process. <<< Marc Lindsey Reply >>> I very much appreciate the implications of the LRSA. But I don't see how my proposal punishes organizations that have signed an LRSA - the LRSA's terms and conditions would be no more burdensome than they are today. My proposal does acknowledge that legacy numbers under LRSA are essentially the same as regular numbers; and legacy numbers not under contract are different than regular numbers. As I read your statement, I was struck by your premise that getting holders of legacy numbers to sign the LRSA and, as result, strip legacy numbers of their legacy status is an important policy goal. I don't think it should be. And even if you or others think (as a matter of principle) eliminating the two classes of numbers is desirable, continuing to push, as an organization, for this ideal shouldn't be more important than the accuracy of the registration databases. Owen wrote: Removal of needs basis from section 8.2 is also not desirable, IMHO. <<< Marc Lindsey Reply >>> Why? Companies that merge, divest, acquire assets are making business decisions on how to respond to market factors in their industries. Inserting ARIN's needs justification-based approval into these transactions is unnecessary. But more pragmatically, applying needs justification to 8.2 transfers really only punishes those with regular numbers or numbers under LRSA. My proposal attempts to provide holders of regular numbers with certain enhanced flexibility enjoyed by holders of legacy numbers not under LRSA. Owen wrote: Proposed 8.2.2 should allow the fee to be removed by signing an RSA and not only the LRSA. <<< Marc Lindsey Reply >>> Why? To the extent there is a difference between the LRSA and RSA, why should a successor of a company with legacy resources be asked or even contemplate the RSA instead of the LRSA? Owen wrote: Defining legacy numbers is in error. There are no such things as legacy numbers. There are legacy registrations, numbers which are subject to a legacy registration, and holders of legacy registrations (aka legacy registrants). <<< Marc Lindsey Reply >>> The definition acknowledges the practical reality of the two classes of numbers. Believing that legacy numbers don't exist is obviously your prerogative. But making policy decisions based on their non-existence (which is contrary to long-standing course of dealing) would be, in my opinion, a mistake. Owen wrote: Registrations for which ARIN provides services without a contract are the legacy registrations of concern in the current policy debates and we should, IMHO, seek to minimize the extent to which such registrations are treated differently, not create additional policy to create additional differences in their treatment. <<< Marc Lindsey Reply >>> I think you have just made my point. By eliminating the needs justification when regular numbers are transferred under 8.2, the proposed policy would bring greater parity between the way legacy numbers and regular numbers are passed on from current listed registrants to their lawful successors and assigns. The only distinction is the LRSA/RSA requirement. And this distinction merely preserves the status quo, and eliminates a key barrier preventing many legacy holders from seeking to update the registry databases. Marc Lindsey Levine, Blaszak, Block & Boothby, LLP 2001 L Street, NW Suite 900 Washington, DC 20036 Phone: (202) 857-2564 Email: mlindsey at lb3law.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Jul 6 02:54:42 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 5 Jul 2012 23:54:42 -0700 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements In-Reply-To: <98E8C412B2F47D48A79816422B860E1B04B9EC926E6F@lb3ex01> References: <98E8C412B2F47D48A79816422B860E1B04B9EC926E6F@lb3ex01> Message-ID: <58B14F3B-F7A1-40CE-AC5B-9D2A0AF03F58@delong.com> On Jul 5, 2012, at 10:58 PM, Lindsey, Marc wrote: > Owen, > > Thanks for your (as always) prompt, and less critical-than-expected response. It almost sounds like you could be in favor of the proposal with some further revision. See some additional comments below. > Perhaps... > . . . . > Owen wrote: > FIrst, ARIN has no authority or ability to compel exclusivity. All ARIN can provide is a guarantee that the numbers assigned/allocated are unique among cooperating parties. That is, no other RIR nor the IANA nor ARIN will assign/allocate conflicting numbers to another party. > > <<< Marc Lindsey Reply >>> I think I agree with you, but I?m not sure. Is there something in my proposal that suggests that I believe ARIN has the power to compel non-members to do or not do something? > From the proposal text... 8.1 second paragraph: ... Rather, such number resources are assigned by ARIN to an organization for its exclusive use, ... > . . . . > > Owen wrote: > Creating a policy which is punitive to LRSA signatories is, IMHO, counterproductive. We want to create reasons for legacy registrants to sign LRSAs, not provide additional hurdles to that process. > > <<< Marc Lindsey Reply >>> > I very much appreciate the implications of the LRSA. But I don?t see how my proposal punishes organizations that have signed an LRSA ? the LRSA?s terms and conditions would be no more burdensome than they are today. My proposal does acknowledge that legacy numbers under LRSA are essentially the same as regular numbers; and legacy numbers not under contract are different than regular numbers. > Your proposal 8.2.2 gives an advantage to legacy holders that have not previously signed an LRSA vs. those that have which get treated under 8.2.1. IMHO, all transfer recordings should require the recipient to sign at least an LRSA, but ideally an RSA. > As I read your statement, I was struck by your premise that getting holders of legacy numbers to sign the LRSA and, as result, strip legacy numbers of their legacy status is an important policy goal. I don?t think it should be. And even if you or others think (as a matter of principle) eliminating the two classes of numbers is desirable, continuing to push, as an organization, for this ideal shouldn?t be more important than the accuracy of the registration databases. We can agree to disagree on this. The existence of a group of resource holders who believe that they have an ownership interest in the resources and/or that they are not subject to the policies set forth by the community for which the resources are managed in trust is, IMHO, one of the most problematic areas of number registration. Inaccuracies in the database will eventually get resolved by RPKI and the desire of ISPs not to route resources which are not properly registered. > > Owen wrote: Removal of needs basis from section 8.2 is also not desirable, IMHO. > > <<< Marc Lindsey Reply >>> Why? Companies that merge, divest, acquire assets are making business decisions on how to respond to market factors in their industries. Inserting ARIN?s needs justification-based approval into these transactions is unnecessary. But more pragmatically, applying needs justification to 8.2 transfers really only punishes those with regular numbers or numbers under LRSA. My proposal attempts to provide holders of regular numbers with certain enhanced flexibility enjoyed by holders of legacy numbers not under LRSA. That argument flies about as well as eliminating needs basis from address acquisition from the free pool IMHO. You assume and assert that legacy holders not under RSA enjoy that privilege, but it isn't necessarily true in fact. Nothing prevents ARIN from removing the registration from the database upon discovery that the original legacy organization is no longer using the resources and/or no longer exists. At that point, ARIN is free to register the resources to another deserving party with need. > > Owen wrote: Proposed 8.2.2 should allow the fee to be removed by signing an RSA and not only the LRSA. > > <<< Marc Lindsey Reply >>> Why? To the extent there is a difference between the LRSA and RSA, why should a successor of a company with legacy resources be asked or even contemplate the RSA instead of the LRSA? First, ideally, they would not be offered the LRSA. Those differences (which are fewer than ever before, admittedly) are intended as an enticement to bring legacy registrants into the community. Upon transfer, resources should lose their legacy status IMHO. > Owen wrote: Defining legacy numbers is in error. There are no such things as legacy numbers. There are legacy registrations, numbers which are subject to a legacy registration, and holders of legacy registrations (aka legacy registrants). > > > <<< Marc Lindsey Reply >>> The definition acknowledges the practical reality of the two classes of numbers. Believing that legacy numbers don?t exist is obviously your prerogative. But making policy decisions based on their non-existence (which is contrary to long-standing course of dealing) would be, in my opinion, a mistake. Try to read what I wrote more carefully. I am not saying there are not two classes of registrations. I am saying that it is the registration status which is legacy and not the numbers themselves. Numbers that are legacy absolutely stop being legacy when transferred under 8.3. They should stop being legacy when transferred under 8.2. > > Owen wrote: Registrations for which ARIN provides services without a contract are the legacy registrations of concern in the current policy debates and we should, IMHO, seek to minimize the extent to which such registrations are treated differently, not create additional policy to create additional differences in their treatment. > > <<< Marc Lindsey Reply >>> I think you have just made my point. By eliminating the needs justification when regular numbers are transferred under 8.2, the proposed policy would bring greater parity between the way legacy numbers and regular numbers are passed on from current listed registrants to their lawful successors and assigns. The only distinction is the LRSA/RSA requirement. And this distinction merely preserves the status quo, and eliminates a key barrier preventing many legacy holders from seeking to update the registry databases. Your statement assumes facts not in evidence... Namely that 8.2 transfers sourced from legacy registrants are not subject to needs basis. I do not believe that is the case. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Jul 6 10:28:48 2012 From: farmer at umn.edu (David Farmer) Date: Fri, 06 Jul 2012 09:28:48 -0500 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <4F806A19-842D-44C6-8ACD-D4306EC8EFF6@delong.com> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> <4FF61419.1030302@umn.edu> <4FF61501.9040707@burnttofu.net> <4FF61DCB.8090100@umn.edu> <4F806A19-842D-44C6-8ACD-D4306EC8EFF6@delong.com> Message-ID: <4FF6F620.5070701@umn.edu> On 7/5/12 18:23 CDT, Owen DeLong wrote: >> If a mom and pop organization changes its name they should be able to update the records with the new name without having to rejustify their use, its not about size. If they we justified under the old name why shouldn't they be justified under the new name? The use didn't change by changing the name. > > You are assuming that 8.2 only covers name changes. It does not. In fact, as I understand it, a name change does not require an 8.2 or 8.3 transfer if you can show that the new name and the old name are the same entity and not an ownership change. John, I thought you clarified this recently, but I couldn't find it when I went looking, so I apologize if you have answered this recently. Can an organization change its name other than trough an 8.2 transfer? Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jcurran at arin.net Fri Jul 6 11:00:02 2012 From: jcurran at arin.net (John Curran) Date: Fri, 6 Jul 2012 15:00:02 +0000 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <4FF6F620.5070701@umn.edu> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> <4FF61419.1030302@umn.edu> <4FF61501.9040707@burnttofu.net> <4FF61DCB.8090100@umn.edu> <4F806A19-842D-44C6-8ACD-D4306EC8EFF6@delong.com> <4FF6F620.5070701@umn.edu> Message-ID: <7668AD90-545C-4934-9A0A-B4E4F4937E03@arin.net> On Jul 6, 2012, at 10:28 AM, David Farmer wrote: > On 7/5/12 18:23 CDT, Owen DeLong wrote: > >>> If a mom and pop organization changes its name they should be able to update the records with the new name without having to rejustify their use, its not about size. If they we justified under the old name why shouldn't they be justified under the new name? The use didn't change by changing the name. >> >> You are assuming that 8.2 only covers name changes. It does not. In fact, as I understand it, a name change does not require an 8.2 or 8.3 transfer if you can show that the new name and the old name are the same entity and not an ownership change. > > John, > > I thought you clarified this recently, but I couldn't find it when I went looking, so I apologize if you have answered this recently. > > Can an organization change its name other than trough an 8.2 transfer? A legal name change is not considered a request under the transfer policies, and as such does not require an organization to provide justification of their space per documented need. We do require proper legal documentation in order to process a name change. FYI, /John John Curran President and CEO ARIN From hostmaster at gfoster.com Fri Jul 6 11:05:10 2012 From: hostmaster at gfoster.com (hostmaster at gfoster.com) Date: Fri, 6 Jul 2012 11:05:10 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <7668AD90-545C-4934-9A0A-B4E4F4937E03@arin.net> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> <4FF61419.1030302@umn.edu> <4FF61501.9040707@burnttofu.net> <4FF61DCB.8090100@umn.edu> <4F806A19-842D-44C6-8ACD-D4306EC8EFF6@delong.com> <4FF6F620.5070701@umn.edu> <7668AD90-545C-4934-9A0A-B4E4F4937E03@arin.net> Message-ID: <20470.65190.65314.737376@audio.gfoster.com> John Curran writes: > We do require proper legal documentation in order to process a name > change. What the heck is "proper legal documentation?" I am a one-person consulting firm with a legacy assignment circa 1993, why can't I call my business whatever I want, or several names for that matter? From jcurran at arin.net Fri Jul 6 11:23:32 2012 From: jcurran at arin.net (John Curran) Date: Fri, 6 Jul 2012 15:23:32 +0000 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <20470.65190.65314.737376@audio.gfoster.com> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> <4FF61419.1030302@umn.edu> <4FF61501.9040707@burnttofu.net> <4FF61DCB.8090100@umn.edu> <4F806A19-842D-44C6-8ACD-D4306EC8EFF6@delong.com> <4FF6F620.5070701@umn.edu> <7668AD90-545C-4934-9A0A-B4E4F4937E03@arin.net> <20470.65190.65314.737376@audio.gfoster.com> Message-ID: <4EE9F0E5-22C4-4D09-8B90-78E443B37DC0@corp.arin.net> On Jul 6, 2012, at 11:05 AM, hostmaster at gfoster.com wrote: > John Curran writes: > >> We do require proper legal documentation in order to process a name >> change. > > What the heck is "proper legal documentation?" > > I am a one-person consulting firm with a legacy assignment circa > 1993, why can't I call my business whatever I want, or several names > for that matter? Depending on your country (and/or state) you likely can call your business whatever you want (referred to in the US as "D/B/A", or "Doing Business As".) However, unless you want resources listed to parties simply "doing business as" a name then hijacked by a different firm "doing business as" the same name, it's necessary to have actually legal entities associated with number resources. If the community would like to change this, it would be trivial to do, but there could easily be significant consequences to be considered. FYI, /John John Curran President and CEO ARIN From tvest at eyeconomics.com Fri Jul 6 13:32:10 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 6 Jul 2012 13:32:10 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements In-Reply-To: <58B14F3B-F7A1-40CE-AC5B-9D2A0AF03F58@delong.com> References: <98E8C412B2F47D48A79816422B860E1B04B9EC926E6F@lb3ex01> <58B14F3B-F7A1-40CE-AC5B-9D2A0AF03F58@delong.com> Message-ID: <5F371FB0-0027-4E61-8617-AB251D0DDEF0@eyeconomics.com> On Jul 6, 2012, at 2:54 AM, Owen DeLong wrote: > > On Jul 5, 2012, at 10:58 PM, Lindsey, Marc wrote: > >> Owen, >> >> Thanks for your (as always) prompt, and less critical-than-expected response. It almost sounds like you could be in favor of the proposal with some further revision. See some additional comments below. >> > > Perhaps... > >> . . . . >> Owen wrote: >> FIrst, ARIN has no authority or ability to compel exclusivity. All ARIN can provide is a guarantee that the numbers assigned/allocated are unique among cooperating parties. That is, no other RIR nor the IANA nor ARIN will assign/allocate conflicting numbers to another party. >> >> <<< Marc Lindsey Reply >>> I think I agree with you, but I?m not sure. Is there something in my proposal that suggests that I believe ARIN has the power to compel non-members to do or not do something? >> > > From the proposal text... > > 8.1 second paragraph: > ... Rather, such number resources are assigned by ARIN to an organization for its exclusive use, ... > >> . . . . >> >> Owen wrote: >> Creating a policy which is punitive to LRSA signatories is, IMHO, counterproductive. We want to create reasons for legacy registrants to sign LRSAs, not provide additional hurdles to that process. >> >> <<< Marc Lindsey Reply >>> >> I very much appreciate the implications of the LRSA. But I don?t see how my proposal punishes organizations that have signed an LRSA ? the LRSA?s terms and conditions would be no more burdensome than they are today. My proposal does acknowledge that legacy numbers under LRSA are essentially the same as regular numbers; and legacy numbers not under contract are different than regular numbers. >> > > Your proposal 8.2.2 gives an advantage to legacy holders that have not previously signed an LRSA vs. those that have which get treated under 8.2.1. > > IMHO, all transfer recordings should require the recipient to sign at least an LRSA, but ideally an RSA. > >> As I read your statement, I was struck by your premise that getting holders of legacy numbers to sign the LRSA and, as result, strip legacy numbers of their legacy status is an important policy goal. I don?t think it should be. And even if you or others think (as a matter of principle) eliminating the two classes of numbers is desirable, continuing to push, as an organization, for this ideal shouldn?t be more important than the accuracy of the registration databases. > > We can agree to disagree on this. The existence of a group of resource holders who believe that they have an ownership interest in the resources and/or that they are not subject to the policies set forth by the community for which the resources are managed in trust is, IMHO, one of the most problematic areas of number registration. hear hear! > Inaccuracies in the database will eventually get resolved by RPKI and the desire of ISPs not to route resources which are not properly registered. I certainly hope that this prediction is borne out, but there are a range of outcomes wherein such "resolutions" would be detrimental to, if not inconsistent with the future security/stability of routing and/or the autonomy of routing service providers. While RPKI may ultimately guarantee the accuracy of associations between a "routed resource" and a "registry record," it does not and cannot guarantee what kinds of information that record will include, or the accuracy of the information that is included (apart from whatever the routing service provider deems necessary to assure payment), or the conditions under which that registration record will be maintained (e.g., as part of a single registration database under unitary management with uniform terms of use/participation, a distributed and/or loosely coordinated WYSIWYG database, etc. -- or the form or terms under which registry records might be accessible to third parties. As IPv4 prefixes become more "liquid," we can expect parties with an ongoing sell-side interest in number resource markets to call for mechanisms (including perhaps RIR policies) to signal routing service providers that resource (x) has undergone a change of beneficial control/ownership status, and so "deserves" a status/reputation reset. Absent such a mechanism -- or alternately, a widespread willingness among routing service providers to ignore prior resource "reputation" information as long as the price is right -- the kind of number resource market that some people want to see emerge simply cannot exist, so demands for such mechanisms are inevitable. [IMO, one can already hear hints of this in the recurring tendency among some ppml contributors to argue "as if" registration status guarantees routability]. Doubtless the proponents of such post-sale reputation reset triggers will argue that their goal is to make market-sourced resources more useful to new entrants, whose only failing is in their arriving too late to obtain their own RIR-delegated resources, and thus whose obligatory inheritance of a purchased resource's lingering bad reputation would only add insult to injury. Unfortunately, (almost?) any conceivable (voluntary, non-hierarchical) mechanism designed to serve that purpose would also make it trivially easy for any operator possessing enough resources to have an ongoing sell-side interest in the number resource market to behave badly at will themselves with complete impunity (or at least, with unassailable "deniability"). Bottom line: the community needs to prioritize it's interests in (a) preserving/maximizing freedom of private action in the provision of commercial routing services, (b) maximizing freedom of private action in the commercial disposition of IP number resources, and (c) preserving/maximizing the possibility of distributed, voluntary, self-help based accountability mechanisms that depend on things like "reputation." Pick one, or two if you're ambitious (and feeling lucky), but there's no way to preserve, much less maximize all three at the same time. TV >> Owen wrote: Removal of needs basis from section 8.2 is also not desirable, IMHO. >> >> <<< Marc Lindsey Reply >>> Why? Companies that merge, divest, acquire assets are making business decisions on how to respond to market factors in their industries. Inserting ARIN?s needs justification-based approval into these transactions is unnecessary. But more pragmatically, applying needs justification to 8.2 transfers really only punishes those with regular numbers or numbers under LRSA. My proposal attempts to provide holders of regular numbers with certain enhanced flexibility enjoyed by holders of legacy numbers not under LRSA. > > That argument flies about as well as eliminating needs basis from address acquisition from the free pool IMHO. > > You assume and assert that legacy holders not under RSA enjoy that privilege, but it isn't necessarily true in fact. Nothing prevents ARIN from removing the registration from the database upon discovery that the original legacy organization is no longer using the resources and/or no longer exists. At that point, ARIN is free to register the resources to another deserving party with need. > >> >> Owen wrote: Proposed 8.2.2 should allow the fee to be removed by signing an RSA and not only the LRSA. >> >> <<< Marc Lindsey Reply >>> Why? To the extent there is a difference between the LRSA and RSA, why should a successor of a company with legacy resources be asked or even contemplate the RSA instead of the LRSA? > > First, ideally, they would not be offered the LRSA. Those differences (which are fewer than ever before, admittedly) are intended as an enticement to bring legacy registrants into the community. Upon transfer, resources should lose their legacy status IMHO. > >> Owen wrote: Defining legacy numbers is in error. There are no such things as legacy numbers. There are legacy registrations, numbers which are subject to a legacy registration, and holders of legacy registrations (aka legacy registrants). >> >> >> <<< Marc Lindsey Reply >>> The definition acknowledges the practical reality of the two classes of numbers. Believing that legacy numbers don?t exist is obviously your prerogative. But making policy decisions based on their non-existence (which is contrary to long-standing course of dealing) would be, in my opinion, a mistake. > > Try to read what I wrote more carefully. > > I am not saying there are not two classes of registrations. I am saying that it is the registration status which is legacy and not the numbers themselves. Numbers that are legacy absolutely stop being legacy when transferred under 8.3. They should stop being legacy when transferred under 8.2. > >> >> Owen wrote: Registrations for which ARIN provides services without a contract are the legacy registrations of concern in the current policy debates and we should, IMHO, seek to minimize the extent to which such registrations are treated differently, not create additional policy to create additional differences in their treatment. >> >> <<< Marc Lindsey Reply >>> I think you have just made my point. By eliminating the needs justification when regular numbers are transferred under 8.2, the proposed policy would bring greater parity between the way legacy numbers and regular numbers are passed on from current listed registrants to their lawful successors and assigns. The only distinction is the LRSA/RSA requirement. And this distinction merely preserves the status quo, and eliminates a key barrier preventing many legacy holders from seeking to update the registry databases. > > Your statement assumes facts not in evidence... Namely that 8.2 transfers sourced from legacy registrants are not subject to needs basis. I do not believe that is the case. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From farmer at umn.edu Fri Jul 6 20:33:19 2012 From: farmer at umn.edu (David Farmer) Date: Fri, 06 Jul 2012 19:33:19 -0500 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <7668AD90-545C-4934-9A0A-B4E4F4937E03@arin.net> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> <4FF61419.1030302@umn.edu> <4FF61501.9040707@burnttofu.net> <4FF61DCB.8090100@umn.edu> <4F806A19-842D-44C6-8ACD-D4306EC8EFF6@delong.com> <4FF6F620.5070701@umn.edu> <7668AD90-545C-4934-9A0A-B4E4F4937E03@arin.net> Message-ID: <4FF783CF.1040600@umn.edu> On 7/6/12 10:00 CDT, John Curran wrote: > On Jul 6, 2012, at 10:28 AM, David Farmer wrote: > >> On 7/5/12 18:23 CDT, Owen DeLong wrote: >> >>>> If a mom and pop organization changes its name they should be able to update the records with the new name without having to rejustify their use, its not about size. If they we justified under the old name why shouldn't they be justified under the new name? The use didn't change by changing the name. >>> >>> You are assuming that 8.2 only covers name changes. It does not. In fact, as I understand it, a name change does not require an 8.2 or 8.3 transfer if you can show that the new name and the old name are the same entity and not an ownership change. >> >> John, >> >> I thought you clarified this recently, but I couldn't find it when I went looking, so I apologize if you have answered this recently. >> >> Can an organization change its name other than trough an 8.2 transfer? > > A legal name change is not considered a request under the transfer > policies, and as such does not require an organization to provide > justification of their space per documented need. John, Thanks for clarifying that. After digging more, I found the instructions to make a legal name change using ARIN Online without going through the transfer process. The Org ID template doesn't allow a legal name change, I guess missed that ARIN Online does. https://www.arin.net/resources/request/org.html#name_change It says "you may need to sign a new Registration Services Agreement". So, does a legacy resource holder need to sign an RSA or LRSA to make a legal name change, if they haven't already signed one? Also it it clearly states "If the name change is part of a merger, acquisition, reorganization, or anything similar, you cannot use this option. Instead, follow the instructions for submitting a transfer request." That's nice and clear, I like that. However, I guess what confused me is the M&A transfer instructions are not equally clear on the converse, that a simple legal name change is not an M&A Transfer. So, without the clear statement to the contrary and the fact that the acceptable types of documentation include documentation of name change. from; https://www.arin.net/resources/request/transfers_8_2.html - Authenticated documentation showing name change, such as - amended articles of incorporation - state/province/federal government verification of name change And, further down on that page in section 6 includes the following that compounds the confusion; https://www.arin.net/resources/request/transfers_8_2.html#step6 "Transferred Internet number resources by virtue of an organization name change, merger, acquisition...", that phrasing could easily be misunderstood that a name change is a transfer. I'll also note that phrasing is not in the fee schedule itself and further seems to imply that there is a fee for a legal name change. However, I don't get that impression from the fee schedule. Is there a fee for a legal name change? Maybe that should be rephrased. So, all that together with the fact that the Org ID template didn't allow a legal name changes confused me into thinking that a name change was processed through an M&A Transfer. I guess the name change documents are an important part of an overall document trail for an M&T transfer, especially if the ORD ID hadn't been updated with a previous legal name change. However, I think making a reference to the legal name change process in step 1 of the M&A Transfer instructions that is equally as clear as the reference to the M&A transfer process within the legal name change process would really clear things up. Also, maybe adding a note to the Org ID template that legal name changes can be requested through ARIN online would be helpful too. I'll send these in through the ACSP as well. Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From farmer at umn.edu Fri Jul 6 20:40:47 2012 From: farmer at umn.edu (David Farmer) Date: Fri, 06 Jul 2012 19:40:47 -0500 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version) In-Reply-To: <4EE9F0E5-22C4-4D09-8B90-78E443B37DC0@corp.arin.net> References: <20120705133137.ec289651d84890fcbef5f195936e1217.f6adbec137.wbe@email17.secureserver.net> <4FF6126A.8020503@burnttofu.net> <4FF61419.1030302@umn.edu> <4FF61501.9040707@burnttofu.net> <4FF61DCB.8090100@umn.edu> <4F806A19-842D-44C6-8ACD-D4306EC8EFF6@delong.com> <4FF6F620.5070701@umn.edu> <7668AD90-545C-4934-9A0A-B4E4F4937E03@arin.net> <20470.65190.65314.737376@audio.gfoster.com> <4EE9F0E5-22C4-4D09-8B90-78E443B37DC0@corp.arin.net> Message-ID: <4FF7858F.1080804@umn.edu> On 7/6/12 10:23 CDT, John Curran wrote: > On Jul 6, 2012, at 11:05 AM, hostmaster at gfoster.com wrote: > >> John Curran writes: >> >>> We do require proper legal documentation in order to process a name >>> change. >> >> What the heck is "proper legal documentation?" >> >> I am a one-person consulting firm with a legacy assignment circa >> 1993, why can't I call my business whatever I want, or several names >> for that matter? > > > Depending on your country (and/or state) you likely can call your > business whatever you want (referred to in the US as "D/B/A", or > "Doing Business As".) However, unless you want resources listed > to parties simply "doing business as" a name then hijacked by a > different firm "doing business as" the same name, it's necessary > to have actually legal entities associated with number resources. > > If the community would like to change this, it would be trivial > to do, but there could easily be significant consequences to be > considered. I'll add that your D/B/A can be changed with a Org ID template just like your address. But you can't change the legal name without proper legal documentation, this is a good thing if you ask me. But, in the case of the person asking the question it sounds like I the legal name is his name. But that's conjecture on my part. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From info at arin.net Wed Jul 11 07:55:42 2012 From: info at arin.net (ARIN) Date: Wed, 11 Jul 2012 07:55:42 -0400 Subject: [arin-ppml] ARIN-prop-177 Revising Section 4.4 C/I Reserved Pool Size (Updated Version) Message-ID: <4FFD69BE.9010909@arin.net> ARIN-prop-177 Revising Section 4.4 C/I Reserved Pool Size The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Revising Section 4.4 C/I Reserved Pool Size Proposal Originator name: Martin Hannigan email: hannigan at gmail.com telephone: unlisted organization: Elected ARIN Advisory Council Member Proposal Version: 2.0 Date: 10 JULY 2012 Proposal type: NEW Policy term: PERMANENT Implementation: When the equivalent of less than a /8 is left in ALL inventory. Policy statement: Change Section 4.4 Paragraph 2 from: ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations. Change Section 4.4 Paragraph 2 to: ARIN will place an equivalent of a /15 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. Rationale: Additional critical infrastructure is being added to the Internet and in a number greater than anticipated when this proposal was written and adopted. The original CI pool was created to serve new IX and new CI requirements. The pending need is estimated in the 600 new gTLD range. With a /24 assignment from the existing boundary and the likelihood of some sharing platforms, assigning a /15 would seem prudent. I have removed the limited term. I have proposed implementation to occur at the point where there is only an equivalent of a /8 available overall. The process for completing the gTLD additions still has some time to play out, but it is likely we will have exhausted by the time that the process does fully play out. From dogwallah at gmail.com Wed Jul 11 10:42:38 2012 From: dogwallah at gmail.com (McTim) Date: Wed, 11 Jul 2012 10:42:38 -0400 Subject: [arin-ppml] ARIN-prop-177 Revising Section 4.4 C/I Reserved Pool Size (Updated Version) In-Reply-To: <4FFD69BE.9010909@arin.net> References: <4FFD69BE.9010909@arin.net> Message-ID: On Wed, Jul 11, 2012 at 7:55 AM, ARIN wrote: > ARIN-prop-177 Revising Section 4.4 C/I Reserved Pool Size > > The proposal originator revised the proposal. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > Policy Proposal Name: Revising Section 4.4 C/I Reserved Pool Size > Proposal Originator > name: Martin Hannigan > email: hannigan at gmail.com > telephone: unlisted > organization: Elected ARIN Advisory Council Member > Proposal Version: 2.0 > Date: 10 JULY 2012 > Proposal type: NEW > Policy term: PERMANENT > Implementation: When the equivalent of less than a /8 is left in ALL > inventory. > Policy statement: > > > Change Section 4.4 Paragraph 2 from: > > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. > > Change Section 4.4 Paragraph 2 to: > > ARIN will place an equivalent of a /15 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. I support this change. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From farmer at umn.edu Wed Jul 11 12:40:50 2012 From: farmer at umn.edu (David Farmer) Date: Wed, 11 Jul 2012 11:40:50 -0500 Subject: [arin-ppml] ARIN-prop-177 Revising Section 4.4 C/I Reserved Pool Size (Updated Version) In-Reply-To: <4FFD69BE.9010909@arin.net> References: <4FFD69BE.9010909@arin.net> Message-ID: <4FFDAC92.8020608@umn.edu> I support both the concept of this policy and the change. However, I am concerned with the details of its implementation. My interruption is that the new version calls for the current text of 4.4 to remain in place until "the equivalent of less than a /8 is left in ALL inventory" and at that point the new text would be put in the NRPM and the equilivant of a /15 would be reserved. I think I would prefer, that the text be updated immediately and the reservation be implemented at the stated trigger point. I believe the way to achieve that outcome is to call for immediate implementation and modify the text to include the trigger. Thanks On 7/11/12 06:55 CDT, ARIN wrote: ... > Implementation: When the equivalent of less than a /8 is left in ALL > inventory. > Policy statement: > > > Change Section 4.4 Paragraph 2 from: > > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. > > Change Section 4.4 Paragraph 2 to: > > ARIN will place an equivalent of a /15 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. > > Rationale: > > Additional critical infrastructure is being added to the Internet and > in a number greater than anticipated when this proposal was written > and adopted. > > The original CI pool was created to serve new IX and new CI requirements. > The pending need is estimated in the 600 new gTLD range. With a /24 > assignment from the existing boundary and the likelihood of some sharing > platforms, assigning a /15 would seem prudent. I have removed the limited > term. I have proposed implementation to occur at the point where there is > only an equivalent of a /8 available overall. The process for > completing the > gTLD additions still has some time to play out, but it is likely we will > have exhausted by the time that the process does fully play out. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From narten at us.ibm.com Fri Jul 13 00:53:03 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 13 Jul 2012 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201207130453.q6D4r3am019073@rotala.raleigh.ibm.com> Total of 13 messages in the last 7 days. script run at: Fri Jul 13 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 30.77% | 4 | 24.23% | 34012 | farmer at umn.edu 7.69% | 1 | 23.21% | 32588 | owen at delong.com 15.38% | 2 | 8.91% | 12516 | jcurran at arin.net 7.69% | 1 | 14.60% | 20498 | mlindsey at lb3law.com 7.69% | 1 | 10.68% | 14992 | tvest at eyeconomics.com 7.69% | 1 | 5.26% | 7385 | narten at us.ibm.com 7.69% | 1 | 4.66% | 6547 | dogwallah at gmail.com 7.69% | 1 | 4.40% | 6178 | info at arin.net 7.69% | 1 | 4.05% | 5684 | hostmaster at gfoster.com --------+------+--------+----------+------------------------ 100.00% | 13 |100.00% | 140400 | Total From info at arin.net Fri Jul 13 10:55:54 2012 From: info at arin.net (ARIN) Date: Fri, 13 Jul 2012 10:55:54 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - June 2012 In-Reply-To: <4FEA0FBE.9070205@arin.net> References: <4FEA0FBE.9070205@arin.net> Message-ID: <500036FA.7050209@arin.net> > The AC abandoned proposals 168, 170, 171 and 172. Anyone dissatisfied > with these decisions may initiate a petition. The petition to advance > a proposal would be the "Discussion Petition." The deadline to begin > a petition will be five business days after the AC's draft meeting > minutes are published. The minutes of the AC's 21 June 2012 meeting have been published and are available at: https://www.arin.net/about_us/ac/index.html The deadline to begin a petition is 20 July 2012. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 6/26/12 3:38 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process, the ARIN > Advisory Council (AC) held a meeting on 21 June 2012 and made > decisions about several draft policies and proposals. > > The AC abandoned the following proposals: > > ARIN-prop-168 Promote 4byte ASN Usage > > ARIN-prop-170 Transfer of Number Resources in case of Bankruptcy > > ARIN-prop-171 Section 8.4 Modifications: ASN and legacy resources > > ARIN-prop-172 Additional definition for NRPM Section 2 - Legacy Resources > > The AC provides the following statements about these proposals: > > "The AC felt that ARIN-prop-168 was overly complex, and that it was > unclear how the proposal would accomplish the stated goal of > "Promoting 4byte ASN Usage". Based on that assessment, the lack of > support on PPML, and confirmation from ARIN staff that no policy > changes are necessary for an organization to request and receive a > 4-byte ASN, the ARIN AC chose to abandon ARIN-prop-168." > > "Based on feedback from PPML and from the proposal originator, the > ARIN AC chose to abandon ARIN-prop-170. The proposal would not have > resulted in an actual policy change, but would simply have codified > existing staff practice. In addition, after the recent adoption of > 2012-3 ASN transfers, the AC saw little need for further policy in > this area." > > "Based on the strong opposition to and weak support for proposal 171 > expressed on the PPML along with the concerns expressed by staff in > the clarity and understanding, the AC abandoned proposal 171." > > "Based on opposition to the proposal from PPML, ongoing discussions > about the linkage of Proposal 172 to Proposal 171, and possible future > needs for a definition such as was included in Proposal 172, the AC > decided to abandon Proposal 172, with intent to re-address the issues > raised therein at a later date." > > The AC abandoned proposals 168, 170, 171 and 172. Anyone dissatisfied > with these decisions may initiate a petition. The petition to advance > a proposal would be the "Discussion Petition." The deadline to begin a > petition will be five business days after the AC's draft meeting > minutes are published. For more information on starting and > participating in petitions, see PDP Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > From info at arin.net Fri Jul 13 15:06:22 2012 From: info at arin.net (ARIN) Date: Fri, 13 Jul 2012 15:06:22 -0400 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources Message-ID: <500071AE.70105@arin.net> ARIN-prop-178 Regional Use of Resources ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-178 Regional Use of Resources Proposal Originator: David Farmer Date: 13 July 2012 Proposal type: New Policy term: Permanent Policy statement: Add the following as a new policy section, substituting the actual section number selected for X: X. Regional Use of Resources All requests for number resources must meet the following criteria regarding regional use of resources, in addition to any resource specific criteria. X.1 Use in ARIN Region All organizations are entitled to receive resources from ARIN for use inside the ARIN service region and may use an incidental total of its ARIN registered resources outside the region. One eighth (or 12.5%) of said resources by each type, but no less than a /24 for IPv4, a /48 for IPv6, and one ASN, are considered incidental for this purpose. X.2. Headquartered in the ARIN Region Only organizations headquartered in the ARIN service region are entitled to receive resources from ARIN for use outside the region, in excess of the incidental use defined above, to operate a connected multi-region network, provided they have not received any resources for the same infrastructure from another RIR. If such an organization has received any resources from another RIR, an operational justification is required to clarify how the resources from ARIN will not duplicate any resources from another RIR. However, it is never justified to receive resources from ARIN and another RIR in order to evade another RIR?s policies, or solely based on the availability of resources from another RIR, or the lack thereof. X.3. Preceding Use of Resources All ARIN registered resources received and used outside the ARIN region prior to implementation of this policy, may continue to be used outside the ARIN region. However, such resources are counted toward an organization?s incidental use outside the region, unless the resources qualify under X.2. X.4. Critical Infrastructure Exempt All resources received under any RIR's critical infrastructure policy or equivalent, are exempt from this policy, due to their small resource impact and importance to Internet stability and operations. X.5. Use in Multiple Locations Any resource used simultaneously in multiple locations, like an anycast prefix or ASN, is considered used inside the region, provided at least one of the locations is inside the region, regardless of how many other locations outside the region its also used. X.6. Service Region and Headquarters when received The service region in effect and headquarters location of an organization when resources were originally received applies to any utilization review of those resources. Rationale: The primary purpose of this policy is to determine who is entitled to request new resources, either by direct assignment, allocation, or transfer, from ARIN and for use in what service regions. The following summarizes the essence of it: ? Anyone (either from inside or outside the region) may receive resources for use (fulfilling operational need) inside the ARIN region and use a small amount outside the region. ? Anyone headquartered (primary center of business or administrative operations) inside the ARIN region may receive resources for use in a globally connected network, only if they have not received resources from another RIR for the same purpose. If they have received any resources from another RIR, they must explain how the ARIN resources requested are not intended for the same purpose. There are numerous operational justifications for requesting resources from ARIN for use outside the region and from other RIRs. The justification is necessary to override any assumption that the resources duplicate each other. The following are just a few common examples: ? It may be necessary to use resources from another RIR to meet legal or regulatory requirements, or prevailing operational expectations, in some economies around the world. In such cases it is justified to also receive minimal resources from another RIR for use in those economies instead of using resources received from ARIN. ? If an organization operates a connected network in some regions, but disconnected networks in other regions, the disconnected networks must receive resources from other RIRs. ? If an organization receives resources from one or more other RIRs, without additional justification such as above, only an incidental amount of ARIN resources may be used within those regions. ARIN resources may be used in the other regions where resources were not received. Why 12.5% for incidental? First thought was simply a 90-10 rule, but 12.5% or 1/8th works better with powers of 2 and bit boundary prefixes. Example: an organization that has a /20 from ARIN can simply use up to a /23 outside the region, whereas 10% would result in an ugly fraction of 1.6 /24s, instead of the simple /23 of 12.5%. The other limits set a floor for each type of resource to ensure that all organizations have an operationally useful amount of resources for use outside the region. A /24 for IPv4 and a /48 for IPv6 were selected as they are fairly common minimum prefix sizes allowed and a fraction of an ASN doesn?t make much sense. To facilitate X.6 it is recommended ARIN should publish and maintain a reference timeline of changes in the service region for ARIN and its predecessor registries. But we?re not headquartered in the ARIN region and are using more than an incidental amount of ARIN resources outside the region, do we have to return resources? No, this policy primarily determines who is entitled to receive new resources from ARIN and X.3 explicitly allows you to continue to use those resources outside the region. However, if you are currently using more than 12.5% of your ARIN resources outside the ARIN region then going forward, you are not entitled to receive additional resources for use outside the ARIN region. If those resources were received some time ago when the services regions were different, they may not count against your incidental use because of X.6. Alternatives to this proposal: What if the most restrictive regional hierarchy were used instead? Restricting the use of all resources to only within the region of the RIR that allocated them. This would require an organization needing addresses for a single globally connected infrastructure to get five separate unaggregatable allocations, even if the organization would be willing and able to operate under a single globally aggregatable allocation, this should especially be possible in IPv6. This will cause at least some unnecessary route table growth. Additionally, organizations would be required to deal with all five RIRs, even if this doesn?t provide additional value. Many organizations have only small needs outside one or two of the RIRs, dealing with all five RIRs may not provide additional value in such cases. Some organizations may not be able to justify minimum allocations in all five RIRs, while easily justifying a minimum allocation within at least one RIR or on an overall global basis. However, this strict interpretation of regional hierarchy ensures overall stewardship on a global basis. What if the most liberal regional hierarchy were used instead? Allowing an organization to obtain resources from one or all five RIRs and use those resources completely unrestricted on a global basis. This solves most of the drawbacks of the strict regional hierarchy. However, taken to an extreme, this could allow an organization to obtain as much as five times its justifiable global need, creating an obvious stewardship issue on a global basis, this is the primary drawback of this option. Also, it is difficult to understand what functional purpose defining regions actually serves with this option. Finally, with IPv4 run-out this option has the additional drawback of allowing completely unrestricted RIR shopping. Benefits to this Proposal: The RIR System was created to facilitate stewardship within the global Internet allowing for better interactions with users and ISPs by providing support during operational hours, in languages and with cultural understanding appropriate to and under the control of each region. This can only be accomplished if the RIR?s regions have at least some meaning. However, an overly strict interpretation of the regions will create operational inefficiencies for many networks and for the Internet as a whole in other cases. This policy creates a framework providing necessary flexibility for the community, while ensuring overall stewardship of resources on a global basis. The genesis of this policy is from the ARIN XXVII Policy Experience Report and the outcome of the discussions of ARIN-2011-13 at ARIN XXVIII. This policy is intended to be generally consistent with current practice and community intent while formally spelling out and clarifying several aspects that are currently open to interpretation. Further, this policy explicitly seeks to head off risks of RIR shopping based on free pool availability. Concerns regarding this were expressed by the community and in the ARIN XXVII Policy Experience Report. Timetable for implementation: Immediate From info at arin.net Fri Jul 13 16:42:29 2012 From: info at arin.net (ARIN) Date: Fri, 13 Jul 2012 16:42:29 -0400 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources Message-ID: <50008835.3080802@arin.net> ARIN-prop-178 Regional Use of Resources Resending a better formatted version. ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-178 Regional Use of Resources Proposal Originator: David Farmer Date: 13 July 2012 Proposal type: New Policy term: Permanent Policy statement: Add the following as a new policy section, substituting the actual section number selected for X: X. Regional Use of Resources All requests for number resources must meet the following criteria regarding regional use of resources, in addition to any resource specific criteria. X.1 Use in ARIN Region All organizations are entitled to receive resources from ARIN for use inside the ARIN service region and may use an incidental total of its ARIN registered resources outside the region. One eighth (or 12.5%) of said resources by each type, but no less than a /24 for IPv4, a /48 for IPv6, and one ASN, are considered incidental for this purpose. X.2. Headquartered in the ARIN Region Only organizations headquartered in the ARIN service region are entitled to receive resources from ARIN for use outside the region, in excess of the incidental use defined above, to operate a connected multi-region network, provided they have not received any resources for the same infrastructure from another RIR. If such an organization has received any resources from another RIR, an operational justification is required to clarify how the resources from ARIN will not duplicate any resources from another RIR. However, it is never justified to receive resources from ARIN and another RIR in order to evade another RIR'?s policies, or solely based on the availability of resources from another RIR, or the lack thereof. X.3. Preceding Use of Resources All ARIN registered resources received and used outside the ARIN region prior to implementation of this policy, may continue to be used outside the ARIN region. However, such resources are counted toward an organization'?s incidental use outside the region, unless the resources qualify under X.2. X.4. Critical Infrastructure Exempt All resources received under any RIR's critical infrastructure policy or equivalent, are exempt from this policy, due to their small resource impact and importance to Internet stability and operations. X.5. Use in Multiple Locations Any resource used simultaneously in multiple locations, like an anycast prefix or ASN, is considered used inside the region, provided at least one of the locations is inside the region, regardless of how many other locations outside the region its also used. X.6. Service Region and Headquarters when received The service region in effect and headquarters location of an organization when resources were originally received applies to any utilization review of those resources. Rationale: The primary purpose of this policy is to determine who is entitled to request new resources, either by direct assignment, allocation, or transfer, from ARIN and for use in what service regions. The following summarizes the essence of it: ?* Anyone (either from inside or outside the region) may receive resources for use (fulfilling operational need) inside the ARIN region and use a small amount outside the region. ?* Anyone headquartered (primary center of business or administrative operations) inside the ARIN region may receive resources for use in a globally connected network, only if they have not received resources from another RIR for the same purpose. If they have received any resources from another RIR, they must explain how the ARIN resources requested are not intended for the same purpose. There are numerous operational justifications for requesting resources from ARIN for use outside the region and from other RIRs. The justification is necessary to override any assumption that the resources duplicate each other. The following are just a few common examples: ?* It may be necessary to use resources from another RIR to meet legal or regulatory requirements, or prevailing operational expectations, in some economies around the world. In such cases it is justified to also receive minimal resources from another RIR for use in those economies instead of using resources received from ARIN. ?* If an organization operates a connected network in some regions, but disconnected networks in other regions, the disconnected networks must receive resources from other RIRs. ?* If an organization receives resources from one or more other RIRs, without additional justification such as above, only an incidental amount of ARIN resources may be used within those regions. ARIN resources may be used in the other regions where resources were not received. Why 12.5% for incidental? First thought was simply a 90-10 rule, but 12.5% or 1/8th works better with powers of 2 and bit boundary prefixes. Example: an organization that has a /20 from ARIN can simply use up to a /23 outside the region, whereas 10% would result in an ugly fraction of 1.6 /24s, instead of the simple /23 of 12.5%. The other limits set a floor for each type of resource to ensure that all organizations have an operationally useful amount of resources for use outside the region. A /24 for IPv4 and a /48 for IPv6 were selected as they are fairly common minimum prefix sizes allowed and a fraction of an ASN doesn't make much sense. To facilitate X.6 it is recommended ARIN should publish and maintain a reference timeline of changes in the service region for ARIN and its predecessor registries. But we're not headquartered in the ARIN region and are using more than an incidental amount of ARIN resources outside the region, do we have to return resources? No, this policy primarily determines who is entitled to receive new resources from ARIN and X.3 explicitly allows you to continue to use those resources outside the region. However, if you are currently using more than 12.5% of your ARIN resources outside the ARIN region then going forward, you are not entitled to receive additional resources for use outside the ARIN region. If those resources were received some time ago when the services regions were different, they may not count against your incidental use because of X.6. Alternatives to this proposal: What if the most restrictive regional hierarchy were used instead? Restricting the use of all resources to only within the region of the RIR that allocated them. This would require an organization needing addresses for a single globally connected infrastructure to get five separate unaggregatable allocations, even if the organization would be willing and able to operate under a single globally aggregatable allocation, this should especially be possible in IPv6. This will cause at least some unnecessary route table growth. Additionally, organizations would be required to deal with all five RIRs, even if this doesn't provide additional value. Many organizations have only small needs outside one or two of the RIRs, dealing with all five RIRs may not provide additional value in such cases. Some organizations may not be able to justify minimum allocations in all five RIRs, while easily justifying a minimum allocation within at least one RIR or on an overall global basis. However, this strict interpretation of regional hierarchy ensures overall stewardship on a global basis. What if the most liberal regional hierarchy were used instead? Allowing an organization to obtain resources from one or all five RIRs and use those resources completely unrestricted on a global basis. This solves most of the drawbacks of the strict regional hierarchy. However, taken to an extreme, this could allow an organization to obtain as much as five times its justifiable global need, creating an obvious stewardship issue on a global basis, this is the primary drawback of this option. Also, it is difficult to understand what functional purpose defining regions actually serves with this option. Finally, with IPv4 run-out this option has the additional drawback of allowing completely unrestricted RIR shopping. Benefits to this Proposal: The RIR System was created to facilitate stewardship within the global Internet allowing for better interactions with users and ISPs by providing support during operational hours, in languages and with cultural understanding appropriate to and under the control of each region. This can only be accomplished if the RIR?s regions have at least some meaning. However, an overly strict interpretation of the regions will create operational inefficiencies for many networks and for the Internet as a whole in other cases. This policy creates a framework providing necessary flexibility for the community, while ensuring overall stewardship of resources on a global basis. The genesis of this policy is from the ARIN XXVII Policy Experience Report and the outcome of the discussions of ARIN-2011-13 at ARIN XXVIII. This policy is intended to be generally consistent with current practice and community intent while formally spelling out and clarifying several aspects that are currently open to interpretation. Further, this policy explicitly seeks to head off risks of RIR shopping based on free pool availability. Concerns regarding this were expressed by the community and in the ARIN XXVII Policy Experience Report. Timetable for implementation: Immediate From babydr at baby-dragons.com Fri Jul 13 18:27:03 2012 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Fri, 13 Jul 2012 14:27:03 -0800 (AKDT) Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <50008835.3080802@arin.net> References: <50008835.3080802@arin.net> Message-ID: Hello All , I for one really disagree with such verbage . Due to ... 1 ) UnEnforcability . 2 ) Limit'ting resource usage . I am quite sure others can & will provide other & more concise reasoning than mine . Twyl , JimL On Fri, 13 Jul 2012, ARIN wrote: > ARIN-prop-178 Regional Use of Resources > > Resending a better formatted version. > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-178 Regional Use of Resources > > Proposal Originator: David Farmer > > Date: 13 July 2012 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following as a new policy section, substituting the actual > section number selected for X: > > X. Regional Use of Resources > > All requests for number resources must meet the following criteria > regarding regional use of resources, in addition to any resource > specific criteria. > > X.1 Use in ARIN Region > > All organizations are entitled to receive resources from ARIN for use > inside the ARIN service region and may use an incidental total of its > ARIN registered resources outside the region. One eighth (or 12.5%) of > said resources by each type, but no less than a /24 for IPv4, a /48 for > IPv6, and one ASN, are considered incidental for this purpose. > > X.2. Headquartered in the ARIN Region > > Only organizations headquartered in the ARIN service region are entitled > to receive resources from ARIN for use outside the region, in excess of > the incidental use defined above, to operate a connected multi-region > network, provided they have not received any resources for the same > infrastructure from another RIR. > > If such an organization has received any resources from another RIR, an > operational justification is required to clarify how the resources from > ARIN will not duplicate any resources from another RIR. However, it is > never justified to receive resources from ARIN and another RIR in order > to evade another RIR'?s policies, or solely based on the availability of > resources from another RIR, or the lack thereof. > > X.3. Preceding Use of Resources > > All ARIN registered resources received and used outside the ARIN region > prior to implementation of this policy, may continue to be used outside > the ARIN region. However, such resources are counted toward an > organization'?s incidental use outside the region, unless the resources > qualify under X.2. > > X.4. Critical Infrastructure Exempt > > All resources received under any RIR's critical infrastructure policy or > equivalent, are exempt from this policy, due to their small resource > impact and importance to Internet stability and operations. > > X.5. Use in Multiple Locations > > Any resource used simultaneously in multiple locations, like an anycast > prefix or ASN, is considered used inside the region, provided at least > one of the locations is inside the region, regardless of how many other > locations outside the region its also used. > > X.6. Service Region and Headquarters when received > > The service region in effect and headquarters location of an > organization when resources were originally received applies to any > utilization review of those resources. > > Rationale: > > The primary purpose of this policy is to determine who is entitled to > request new resources, either by direct assignment, allocation, or > transfer, from ARIN and for use in what service regions. The following > summarizes the essence of it: > > ?* Anyone (either from inside or outside the region) may receive > resources for use (fulfilling operational need) inside the ARIN region > and use a small amount outside the region. > > ?* Anyone headquartered (primary center of business or administrative > operations) inside the ARIN region may receive resources for use in a > globally connected network, only if they have not received resources > from another RIR for the same purpose. If they have received any > resources from another RIR, they must explain how the ARIN resources > requested are not intended for the same purpose. > > There are numerous operational justifications for requesting resources > from ARIN for use outside the region and from other RIRs. The > justification is necessary to override any assumption that the resources > duplicate each other. The following are just a few common examples: > > ?* It may be necessary to use resources from another RIR to meet legal or > regulatory requirements, or prevailing operational expectations, in some > economies around the world. In such cases it is justified to also > receive minimal resources from another RIR for use in those economies > instead of using resources received from ARIN. > > ?* If an organization operates a connected network in some regions, but > disconnected networks in other regions, the disconnected networks must > receive resources from other RIRs. > > ?* If an organization receives resources from one or more other RIRs, > without additional justification such as above, only an incidental > amount of ARIN resources may be used within those regions. ARIN > resources may be used in the other regions where resources were not > received. > > Why 12.5% for incidental? First thought was simply a 90-10 rule, but > 12.5% or 1/8th works better with powers of 2 and bit boundary prefixes. > Example: an organization that has a /20 from ARIN can simply use up to > a /23 outside the region, whereas 10% would result in an ugly fraction > of 1.6 /24s, instead of the simple /23 of 12.5%. The other limits set a > floor for each type of resource to ensure that all organizations have an > operationally useful amount of resources for use outside the region. A > /24 for IPv4 and a /48 for IPv6 were selected as they are fairly common > minimum prefix sizes allowed and a fraction of an ASN doesn't make much > sense. > > To facilitate X.6 it is recommended ARIN should publish and maintain a > reference timeline of changes in the service region for ARIN and its > predecessor registries. > > But we're not headquartered in the ARIN region and are using more than > an incidental amount of ARIN resources outside the region, do we have to > return resources? No, this policy primarily determines who is entitled > to receive new resources from ARIN and X.3 explicitly allows you to > continue to use those resources outside the region. However, if you are > currently using more than 12.5% of your ARIN resources outside the ARIN > region then going forward, you are not entitled to receive additional > resources for use outside the ARIN region. If those resources were > received some time ago when the services regions were different, they > may not count against your incidental use because of X.6. > > Alternatives to this proposal: > > What if the most restrictive regional hierarchy were used instead? > Restricting the use of all resources to only within the region of the > RIR that allocated them. This would require an organization needing > addresses for a single globally connected infrastructure to get five > separate unaggregatable allocations, even if the organization would be > willing and able to operate under a single globally aggregatable > allocation, this should especially be possible in IPv6. This will cause > at least some unnecessary route table growth. Additionally, > organizations would be required to deal with all five RIRs, even if this > doesn't provide additional value. Many organizations have only small > needs outside one or two of the RIRs, dealing with all five RIRs may not > provide additional value in such cases. Some organizations may not be > able to justify minimum allocations in all five RIRs, while easily > justifying a minimum allocation within at least one RIR or on an overall > global basis. However, this strict interpretation of regional hierarchy > ensures overall stewardship on a global basis. > > What if the most liberal regional hierarchy were used instead? Allowing > an organization to obtain resources from one or all five RIRs and use > those resources completely unrestricted on a global basis. This solves > most of the drawbacks of the strict regional hierarchy. However, taken > to an extreme, this could allow an organization to obtain as much as > five times its justifiable global need, creating an obvious stewardship > issue on a global basis, this is the primary drawback of this option. > Also, it is difficult to understand what functional purpose defining > regions actually serves with this option. Finally, with IPv4 run-out > this option has the additional drawback of allowing completely > unrestricted RIR shopping. > > Benefits to this Proposal: > > The RIR System was created to facilitate stewardship within the global > Internet allowing for better interactions with users and ISPs by > providing support during operational hours, in languages and with > cultural understanding appropriate to and under the control of each > region. This can only be accomplished if the RIR?s regions have at > least some meaning. However, an overly strict interpretation of the > regions will create operational inefficiencies for many networks and for > the Internet as a whole in other cases. This policy creates a framework > providing necessary flexibility for the community, while ensuring > overall stewardship of resources on a global basis. > > The genesis of this policy is from the ARIN XXVII Policy Experience > Report and the outcome of the discussions of ARIN-2011-13 at ARIN > XXVIII. This policy is intended to be generally consistent with current > practice and community intent while formally spelling out and clarifying > several aspects that are currently open to interpretation. > > Further, this policy explicitly seeks to head off risks of RIR shopping > based on free pool availability. Concerns regarding this were expressed > by the community and in the ARIN XXVII Policy Experience Report. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From mysidia at gmail.com Fri Jul 13 23:36:01 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 13 Jul 2012 22:36:01 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <500071AE.70105@arin.net> References: <500071AE.70105@arin.net> Message-ID: On 7/13/12, ARIN wrote: > X.2. Headquartered in the ARIN Region > > Only organizations headquartered in the ARIN service region are entitled > to receive resources from ARIN for use outside the region, in excess of > the incidental use defined above, to operate a connected multi-region Why both a "Headquartered in the ARIN region" requirement _and_ an incidental use limit? I would say, if an organization is legally recognized by government bodies in the region as an organization that exists, does business in the region, can enter contracts in the region, and owns assets in the region that require IP addresses; they should not be restricted from obtaining resources from ARIN, just because they are headquartered elsewhere. [snip] > If such an organization has received any resources from another RIR, an > operational justification is required to clarify how the resources from > ARIN will not duplicate any resources from another RIR. However, it is > never justified to receive resources from ARIN and another RIR in order > to evade another RIR?s policies, or solely based on the availability of > resources from another RIR, or the lack thereof. [snip] This is a good requirement to be added explicitly; the possibly of an organization applying to multiple RIRs and re-using the same assets to justify two allocations and double the required amount of total resources (but from different regions), should be considered a type of fraud. When applicants provide justification, they should be required to disclose all resources that have been assigned, both from other RIRs, and from any upstream ISPs or other possible sources of IPv4 address resources, that ARIN might not have explicit record of. -- -JH From owen at delong.com Sat Jul 14 00:31:59 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 13 Jul 2012 21:31:59 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> Message-ID: On Jul 13, 2012, at 8:36 PM, Jimmy Hess wrote: > On 7/13/12, ARIN wrote: > >> X.2. Headquartered in the ARIN Region >> >> Only organizations headquartered in the ARIN service region are entitled >> to receive resources from ARIN for use outside the region, in excess of >> the incidental use defined above, to operate a connected multi-region > > Why both a "Headquartered in the ARIN region" requirement _and_ an > incidental use limit? It's not _AND_, it's _OR_ and the exclusive or at that. If you are HQ in the ARIN region, then there is no restriction about out of region use. If you are not HQ in the ARIN region, then, you are allowed incidental use outside of the region. There is no restriction in either case on the amount of resources you can obtain for use within the ARIN region. > I would say, if an organization is legally recognized by government > bodies in the region as > an organization that exists, does business in the region, can enter > contracts in the region, and owns assets in the region that require > IP addresses; they should not be restricted from obtaining resources > from ARIN, just because they are headquartered elsewhere. They are not restricted from obtaining resources from ARIN to use within the ARIN region. They are only restricted on the proportion of ARIN resources that they can use outside of the ARIN region. Do you think that an ISP from out of region should be allowed to set up a small shell company in the US and then obtain unlimited resources from ARIN to use in their operations elsewhere in the world? > > [snip] >> If such an organization has received any resources from another RIR, an >> operational justification is required to clarify how the resources from >> ARIN will not duplicate any resources from another RIR. However, it is >> never justified to receive resources from ARIN and another RIR in order >> to evade another RIR?s policies, or solely based on the availability of >> resources from another RIR, or the lack thereof. > [snip] > > This is a good requirement to be added explicitly; the possibly of an > organization applying to multiple RIRs and re-using the same assets > to justify two allocations and double the required amount of total > resources (but from different regions), > should be considered a type of fraud. > It's in the proposal explicitly. > When applicants provide justification, they should be required to > disclose all resources that have been assigned, both from other RIRs, > and from any upstream ISPs or other possible sources of IPv4 address > resources, that ARIN might not have explicit record of. I believe that's already standard practice. Owen From farmer at umn.edu Sat Jul 14 01:04:19 2012 From: farmer at umn.edu (David Farmer) Date: Sat, 14 Jul 2012 00:04:19 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> Message-ID: <5000FDD3.5000305@umn.edu> On 7/13/12 22:36 CDT, Jimmy Hess wrote: > On 7/13/12, ARIN wrote: > >> X.2. Headquartered in the ARIN Region >> >> Only organizations headquartered in the ARIN service region are entitled >> to receive resources from ARIN for use outside the region, in excess of >> the incidental use defined above, to operate a connected multi-region > > Why both a "Headquartered in the ARIN region" requirement _and_ an > incidental use limit? Its not both, as in "and", but its an "or", if your "Headquartered in Region" there is no limit to your use outside the region, "entitled to receive resources from ARIN for use outside the region, in excess of the incidental use defined above." OR, If your NOT "Headquartered in Region" you are limited to incidental use outside the region, "and may use an incidental total of its ARIN registered resources outside the region". Also, if your "Headquartered in Region" but don't want to deal with the operational justification in X.2 you can still use a small amount of ARIN resources outside the region to say address your backbone, but then get the rest of your addresses from the other RIRs. However, I suggest that "Headquartered in Region" and "Incidental Use" actually serve completely different purposes. The purpose of "Incidental Use" is to provide some flexibility to everyone, even those headquartered outside the region. The intent is not to play "gotcha" with people, or be a "hard ass" about it, we need to make the policy easy to comply with. While still creating a principle of "Regional Use". Basically it says "Your getting resources to use in the ARIN region, but if you need to use a small amount outside the region, go ahead, as long as its small". That's what "Incidental Use" is all about. "Headquartered in Region" serves a completely different purpose. It allows you to get "a single globally aggregatable allocation" if your willing to do that. Without "Headquartered in Region" you have to get 5 separate prefixes to operate a global network, this will create unnecessary growth in the route table and that effects everyone. So "Incidental Use" is about flexibility and "Headquartered in Region" is about global aggregation where possible. > I would say, if an organization is legally recognized by government > bodies in the region as > an organization that exists, does business in the region, can enter > contracts in the region, and owns assets in the region that require > IP addresses; they should not be restricted from obtaining resources > from ARIN, just because they are headquartered elsewhere. There are allowed, everyone is allowed to get resources for use in the ARiN region, that is what X.1 says. X.2 is about who is entitled to get large amounts of resources for use outside the region. Does this need additional clarification in the policy or rationale? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From alh-ietf at tndh.net Sat Jul 14 13:07:07 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Sat, 14 Jul 2012 10:07:07 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> Message-ID: <03a201cd61e3$1ae220b0$50a66210$@tndh.net> Owen DeLong wrote: > ... > > Do you think that an ISP from out of region should be allowed to set up a > small shell company in the US and then obtain unlimited resources from ARIN > to use in their operations elsewhere in the world? >> ... Just a reminder that the address space is a global resource. ARIN is a regional administrator to - facilitate - distribution, just like the other 4. It was not set up to act as a body that hoards everything it can get its hands on. Rewind the clock to ~'96 when IANA handled all distribution, and there was no 'this is mine' mentality. Seriously, 2 year olds in the sandbox do a better job of resource sharing than what we are seeing in the wind-down of the IPv4 pool. I still believe that the best course of action would be for the RIR holding the largest pool to take on the role of IANA and do a monthly/quarterly distribution through any RIR without the resources to meet its customer's needs. This avoids the problem of shell companies in all regions, and the associated short-term bubble staffing demands to review requests; as well as depleting the remaining free pool in an expeditious manner, which avoids absurd distortions in whatever market emerges. IPv4 is a historical artifact, get over it and move on. Arguing over policies intended to hoard the last remaining scraps on the bone is more the domain of the Condor or Jackal than civilized facilitators. Tony From owen at delong.com Sat Jul 14 13:44:05 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Jul 2012 10:44:05 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <03a201cd61e3$1ae220b0$50a66210$@tndh.net> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> Message-ID: On Jul 14, 2012, at 10:07 AM, Tony Hain wrote: > Owen DeLong wrote: >> ... >> >> Do you think that an ISP from out of region should be allowed to set up a >> small shell company in the US and then obtain unlimited resources from > ARIN >> to use in their operations elsewhere in the world? >>> ... > > Just a reminder that the address space is a global resource. ARIN is a > regional administrator to - facilitate - distribution, just like the other > 4. It was not set up to act as a body that hoards everything it can get its > hands on. > > Rewind the clock to ~'96 when IANA handled all distribution, and there was > no 'this is mine' mentality. Seriously, 2 year olds in the sandbox do a > better job of resource sharing than what we are seeing in the wind-down of > the IPv4 pool. > > I still believe that the best course of action would be for the RIR holding > the largest pool to take on the role of IANA and do a monthly/quarterly > distribution through any RIR without the resources to meet its customer's > needs. This avoids the problem of shell companies in all regions, and the > associated short-term bubble staffing demands to review requests; as well as > depleting the remaining free pool in an expeditious manner, which avoids > absurd distortions in whatever market emerges. > > IPv4 is a historical artifact, get over it and move on. Arguing over > policies intended to hoard the last remaining scraps on the bone is more the > domain of the Condor or Jackal than civilized facilitators. > > Tony > Tony, Neither David nor I support hoarding. I absolutely support returning portions of the ARIN free pool to IANA for redistribution to other RIRs. However, what we want to avoid primarily with this policy is RIR policy shopping and/or efforts by members of the other RIRs to essentially circumvent their policies by effectively transferring space into those regions outside of the control of those RIRs. This proposal applies to ASNs and IPv6 resources as well as IPv4. Owen From SRyerse at eclipse-networks.com Sat Jul 14 13:54:41 2012 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Sat, 14 Jul 2012 17:54:41 +0000 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <03a201cd61e3$1ae220b0$50a66210$@tndh.net> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> Message-ID: <5C4532955356D2448E74A170672797E60110E04325@ENI-MAIL.eclipse-networks.com> I strongly agree! Since the day will come quite soon that all of ARIN's IPv4 addresses will be assigned and ARIN will have no more left, it is just a matter of when ARIN allows 3rd parties to transfer IPv4 resources to another party - AND NOT IF ARIN WILL ALLOW IT. Instead of fighting it, ARIN should go ahead and put the necessary reasonable policies in place now for that, and join the reality of the marketplace. ARIN can wait and do it when it runs out of addresses or it can do it now. It is pragmatic to do it now and it allows ARIN a say in how this process will work. If ARIN continues to fight it then a judge somewhere will make the decision for ARIN and then ARIN will have to live with whatever that judge decides - not a good strategy. This will bolster ARIN's ability to fulfill its mission!! Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Tony Hain Sent: Saturday, July 14, 2012 1:07 PM To: 'Owen DeLong'; 'Jimmy Hess' Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-178 Regional Use of Resources Owen DeLong wrote: > ... > > Do you think that an ISP from out of region should be allowed to set > up a small shell company in the US and then obtain unlimited resources > from ARIN > to use in their operations elsewhere in the world? >> ... Just a reminder that the address space is a global resource. ARIN is a regional administrator to - facilitate - distribution, just like the other 4. It was not set up to act as a body that hoards everything it can get its hands on. Rewind the clock to ~'96 when IANA handled all distribution, and there was no 'this is mine' mentality. Seriously, 2 year olds in the sandbox do a better job of resource sharing than what we are seeing in the wind-down of the IPv4 pool. I still believe that the best course of action would be for the RIR holding the largest pool to take on the role of IANA and do a monthly/quarterly distribution through any RIR without the resources to meet its customer's needs. This avoids the problem of shell companies in all regions, and the associated short-term bubble staffing demands to review requests; as well as depleting the remaining free pool in an expeditious manner, which avoids absurd distortions in whatever market emerges. IPv4 is a historical artifact, get over it and move on. Arguing over policies intended to hoard the last remaining scraps on the bone is more the domain of the Condor or Jackal than civilized facilitators. Tony _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From SRyerse at eclipse-networks.com Sat Jul 14 16:03:07 2012 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Sat, 14 Jul 2012 20:03:07 +0000 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <9395E6EE-6B27-4588-82FC-D455B704F48F@delong.com> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <5C4532955356D2448E74A170672797E60110E04325@ENI-MAIL.eclipse-networks.com> <9395E6EE-6B27-4588-82FC-D455B704F48F@delong.com> Message-ID: <5C4532955356D2448E74A170672797E60110E044A1@ENI-MAIL.eclipse-networks.com> Owen, you know more about these processes than I probably ever will - as is obvious from your various post to this community. However, what's really gonna happen in real life is this kind of a scenario: Someone like China Telecom (don't remember their real name) who is controlled by the Chinese Government - is going to decide they want a lot more IPv4 addresses. In fact they want their own /8. Since there aren?t any unassigned /8's for them to get from APNIC (and IANA doesn't have any more to give) they start looking at who is assigned the /8's worldwide. They scan the list of /8 assignee's and come across a curious one that is assigned to Amateur Radio Digital Communications which is the 44.0.0.0 Class A block. If my memory serves me right they are associated with the University of San Diego. I picked this block at random because my Grandfather was an early adopter Ham Radio operator (Hams) in the 1930's. Unfortunately he is a Silent Key now, but I digress. Since China Telecom is controlled by the Chinese government and essentially has very very deep pockets they make a huge offer to the Hams to buy their whole /8 block. They haggle a bit and China Telecom agrees to pay an unbelievable amount of money to the Hams for the whole /8. They sign an agreement with a confidentiality clause in it, and the funds are wired into their bank account immediately, all without ARINs knowledge. While the Hams are sleeping that night dreaming about all of the state of the art radio equipment they are gonna buy with the exorbitant amount of money they just received in their bank account, China Telecom brass visits the CEO of APNIC. They ask the CEO to agree to service their new 44.0.0.0 block and at first he refuses because ARIN has authority over that block and APNIC doesn't. China Telecom then offers APNIC an exorbitant amount of money and of course APNIC agrees to it. The next day this whole transaction is announced to the world and everyone is up in arms over it. ARIN is mad - the other RIR's are mad (although maybe not as much) - IANA is mad - and there is this huge buzz in all the papers and on the Internet about it worldwide. Then while ARIN is publicly trying to refuse to let control of this block go to APNIC, the Chinese President calls up the American President and tells him that China Telecom really needs this /8 block. Further he tells the American President that if he doesn't back his request to move control of the /8 to APNIC - then China will no longer buy America's debt. By the end of the phone call the American President agrees to allow the /8 block to be moved to APNIC, and then his staff calls the powers that be to make this happen - and by nightfall the deal is done. Voila, in a matter of hours ARIN has lost control of a whole /8 and the world's biggest sale of an IPv4 block all happened without any of ARIN's involvement or even their knowledge. China Telecom didn't have to prove to ARIN they needed the block and none of ARIN's policies were followed. ARIN just has to accept it. ARIN didn't even get an administrative fee for this move. This is the way things are done in the real world and in the real marketplace. So Owen, you asked how my comment below applies. This scenario that I have laid out is of course the Armageddon of possibilities, but things like this, and things on a smaller scale can and WILL happen in the future. It is inevitable! So again I say, ARIN can either try and block or stall IPv4 from being transferred between 3rd parties, or ARIN can have the vision and realize the inevitability of what the near future is going to be like - and prepare its policies to accommodate it - and cheerfully administrate it for a reasonable fee. I'll leave it to you and other folks in the community and the folks at ARIN - who know much more about the actual processes than I do, to come up with real world policies to accommodate the inevitable transfer by 3rd parties of IPv4 blocks. When that happens I will applaud those policies in this community. I suspect a lot of other will as well. :-) Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Saturday, July 14, 2012 2:06 PM To: Steven Ryerse Subject: Re: [arin-ppml] ARIN-prop-178 Regional Use of Resources That's already allowed under NRPM 8.3, so I'm not sure what you are talking about or how it relates to proposal 178. Can you clarify? Owen On Jul 14, 2012, at 10:54 AM, Steven Ryerse wrote: > I strongly agree! Since the day will come quite soon that all of ARIN's IPv4 addresses will be assigned and ARIN will have no more left, it is just a matter of when ARIN allows 3rd parties to transfer IPv4 resources to another party - AND NOT IF ARIN WILL ALLOW IT. Instead of fighting it, ARIN should go ahead and put the necessary reasonable policies in place now for that, and join the reality of the marketplace. ARIN can wait and do it when it runs out of addresses or it can do it now. It is pragmatic to do it now and it allows ARIN a say in how this process will work. If ARIN continues to fight it then a judge somewhere will make the decision for ARIN and then ARIN will have to live with whatever that judge decides - not a good strategy. This will bolster ARIN's ability to fulfill its mission!! > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Tony Hain > Sent: Saturday, July 14, 2012 1:07 PM > To: 'Owen DeLong'; 'Jimmy Hess' > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-178 Regional Use of Resources > > Owen DeLong wrote: >> ... >> >> Do you think that an ISP from out of region should be allowed to set >> up a small shell company in the US and then obtain unlimited >> resources from > ARIN >> to use in their operations elsewhere in the world? >>> ... > > Just a reminder that the address space is a global resource. ARIN is a regional administrator to - facilitate - distribution, just like the other 4. It was not set up to act as a body that hoards everything it can get its hands on. > > Rewind the clock to ~'96 when IANA handled all distribution, and there was no 'this is mine' mentality. Seriously, 2 year olds in the sandbox do a better job of resource sharing than what we are seeing in the wind-down of the IPv4 pool. > > I still believe that the best course of action would be for the RIR holding the largest pool to take on the role of IANA and do a monthly/quarterly distribution through any RIR without the resources to meet its customer's needs. This avoids the problem of shell companies in all regions, and the associated short-term bubble staffing demands to review requests; as well as depleting the remaining free pool in an expeditious manner, which avoids absurd distortions in whatever market emerges. > > IPv4 is a historical artifact, get over it and move on. Arguing over policies intended to hoard the last remaining scraps on the bone is more the domain of the Condor or Jackal than civilized facilitators. > > Tony > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Sat Jul 14 16:18:48 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 14 Jul 2012 13:18:48 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <5C4532955356D2448E74A170672797E60110E044A1@ENI-MAIL.eclipse-networks.com> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <5C4532955356D2448E74A170672797E60110E04325@ENI-MAIL.eclipse-networks.com> <9395E6EE-6B27-4588-82FC-D455B704F48F@delong.com> <5C4532955356D2448E74A170672797E60110E044A1@ENI-MAIL.eclipse-networks.com> Message-ID: On Jul 14, 2012, at 1:03 PM, Steven Ryerse wrote: > Owen, you know more about these processes than I probably ever will - as is obvious from your various post to this community. > Meh... > However, what's really gonna happen in real life is this kind of a scenario: > > Someone like China Telecom (don't remember their real name) who is controlled by the Chinese Government - is going to decide they want a lot more IPv4 addresses. In fact they want their own /8. Since there aren?t any unassigned /8's for them to get from APNIC (and IANA doesn't have any more to give) they start looking at who is assigned the /8's worldwide. They scan the list of /8 assignee's and come across a curious one that is assigned to Amateur Radio Digital Communications which is the 44.0.0.0 Class A block. If my memory serves me right they are associated with the University of San Diego. I picked this block at random because my Grandfather was an early adopter Ham Radio operator (Hams) in the 1930's. Unfortunately he is a Silent Key now, but I digress. KB6MER here... I'm well and truly familiar with the situation with 44.0.0.0/8. > Since China Telecom is controlled by the Chinese government and essentially has very very deep pockets they make a huge offer to the Hams to buy their whole /8 block. They haggle a bit and China Telecom agrees to pay an unbelievable amount of money to the Hams for the whole /8. They sign an agreement with a confidentiality clause in it, and the funds are wired into their bank account immediately, all without ARINs knowledge. While the Hams are sleeping that night dreaming about all of the state of the art radio equipment they are gonna buy with the exorbitant amount of money they just received in their bank account, China Telecom brass visits the CEO of APNIC. They ask the CEO to agree to service their new 44.0.0.0 block and at first he refuses because ARIN has authority over that block and APNIC doesn't. China Telecom then offers APNIC an exorbitant amount of money and of course APNIC agrees to it. The next day this whole transaction is announced to the world and everyone is up in arms over it. ARIN is mad - the other RIR's are mad (although maybe not as much) - IANA is mad - and there is this huge buzz in all the papers and on the Internet about it worldwide. That would be pretty difficult to do. There isn't actually anyone with the authority to sell it on behalf of the amateur radio community at large and Amateur radio is a very diverse community. However, let's assume we're talking about a less problematic block such as one held by a corporation that is willing to sell it... APNIC wouldn't agree to that regardless of the amount of money involved because they don't actually have the authority to do so and there is a lot more riding on it than just the money. It would essentially destroy the RIR system and probably land the responsible APNIC executives in jail. APNIC, like all RIRs is organized as a non-proffit for a reason. However, the sale could be done by approaching ARIN and APNIC under current transfer policy and actually conducting the transfer legitimately, presuming that: 1. The holder of the resource can prove that they are the legitimate registrant and agree to the transfer. 2. The recipient meets APNIC criteria for receiving the block (justified need). 3. The RIRs both agree to the transfer (which they will do absent a policy-based reason not to). That is existing policy, so again, I am not sure why you think there is a problem. > Then while ARIN is publicly trying to refuse to let control of this block go to APNIC, the Chinese President calls up the American President and tells him that China Telecom really needs this /8 block. Further he tells the American President that if he doesn't back his request to move control of the /8 to APNIC - then China will no longer buy America's debt. By the end of the phone call the American President agrees to allow the /8 block to be moved to APNIC, and then his staff calls the powers that be to make this happen - and by nightfall the deal is done. Voila, in a matter of hours ARIN has lost control of a whole /8 and the world's biggest sale of an IPv4 block all happened without any of ARIN's involvement or even their knowledge. China Telecom didn't have to prove to ARIN they needed the block and none of ARIN's policies were followed. ARIN just has to accept it. ARIN didn't even get an administrative fee for this move. This presumes so many facts not in evidence and is such wild and improbable speculation built on top of semi-plausible speculation that I simply can't take it seriously. I'm sorry. > This is the way things are done in the real world and in the real marketplace. So Owen, you asked how my comment below applies. This scenario that I have laid out is of course the Armageddon of possibilities, but things like this, and things on a smaller scale can and WILL happen in the future. It is inevitable! So again I say, ARIN can either try and block or stall IPv4 from being transferred between 3rd parties, or ARIN can have the vision and realize the inevitability of what the near future is going to be like - and prepare its policies to accommodate it - and cheerfully administrate it for a reasonable fee. Proposal 178 has _NOTHING_ whatsoever to do with transfers. It only governs receipt and use of space from the ARIN free pool by parties requesting it from ARIN directly and keeping it registered in the ARIN database. Transfers are governed under section 8 which already allows the type of transfer you seem to be concerned about. Please re-read section 8 of the NRPM and then if you still think there is a problem, by all means, attempt to describe the problem such that it can be addressed. However, please make that part of a separate thread as it is utterly and completely unrelated to proposal 178. > I'll leave it to you and other folks in the community and the folks at ARIN - who know much more about the actual processes than I do, to come up with real world policies to accommodate the inevitable transfer by 3rd parties of IPv4 blocks. When that happens I will applaud those policies in this community. I suspect a lot of other will as well. :-) I think you're a little late. You could have started clapping almost a year ago when we first adopted an inter-RIR transfer policy. Heck, in some ways, you could have started clapping in 2009 when we first adopted a specified transfer policy. Owen From farmer at umn.edu Sat Jul 14 16:49:06 2012 From: farmer at umn.edu (David Farmer) Date: Sat, 14 Jul 2012 15:49:06 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <5C4532955356D2448E74A170672797E60110E04325@ENI-MAIL.eclipse-networks.com> <9395E6EE-6B27-4588-82FC-D455B704F48F@delong.com> <5C4532955356D2448E74A170672797E60110E044A1@ENI-MAIL.eclipse-networks.com> Message-ID: <877FC70D-AFEC-47B2-B49C-BF7B42AF8364@umn.edu> On Jul 14, 2012, at 15:18, Owen DeLong wrote: > Proposal 178 has _NOTHING_ whatsoever to do with transfers. It only governs receipt and use of space from the ARIN free pool by parties requesting it from ARIN directly and keeping it registered in the ARIN database. > > Transfers are governed under section 8 which already allows the type of transfer you seem to be concerned about. Please re-read section 8 of the NRPM and then if you still think there is a problem, by all means, attempt to describe the problem such that it can be addressed. However, please make that part of a separate thread as it is utterly and completely unrelated to proposal 178. Well not completely NOTHING to do with transfers. But, I'll agree it has nothing to do with the examples in question, transferring resources out of the ARIN region, that is where the recipient is outside ARIN region and as a result the resources will end up under the control of another RIR. However, It does have a little to do with a transfers within the ARIN region or to the ARIN region, that is where the recipient is inside the ARIN Region and the resources remain or end up under ARIN control. But in this case I believe the policy allows the intended result of such a transfer to a recipient within the region. Steve, and others does that make sense as written? Or, does the policy or rationale need additional clarification on that point? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From mysidia at gmail.com Sat Jul 14 16:59:04 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 14 Jul 2012 15:59:04 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> Message-ID: On 7/13/12, Owen DeLong wrote: > On Jul 13, 2012, at 8:36 PM, Jimmy Hess wrote: > It's not _AND_, it's _OR_ and the exclusive or at that. Apparently I need to re-read this. I support the policy proposed. -- -JH From alh-ietf at tndh.net Sat Jul 14 18:32:36 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Sat, 14 Jul 2012 15:32:36 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> Message-ID: <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> Owen DeLong wrote: > On Jul 14, 2012, at 10:07 AM, Tony Hain wrote: > > > Owen DeLong wrote: > >> ... > >> > >> Do you think that an ISP from out of region should be allowed to set > >> up a small shell company in the US and then obtain unlimited > >> resources from > > ARIN > >> to use in their operations elsewhere in the world? > >>> ... > > > > Just a reminder that the address space is a global resource. ARIN is a > > regional administrator to - facilitate - distribution, just like the > > other 4. It was not set up to act as a body that hoards everything it > > can get its hands on. > > > > Rewind the clock to ~'96 when IANA handled all distribution, and there > > was no 'this is mine' mentality. Seriously, 2 year olds in the sandbox > > do a better job of resource sharing than what we are seeing in the > > wind-down of the IPv4 pool. > > > > I still believe that the best course of action would be for the RIR > > holding the largest pool to take on the role of IANA and do a > > monthly/quarterly distribution through any RIR without the resources > > to meet its customer's needs. This avoids the problem of shell > > companies in all regions, and the associated short-term bubble > > staffing demands to review requests; as well as depleting the > > remaining free pool in an expeditious manner, which avoids absurd > distortions in whatever market emerges. > > > > IPv4 is a historical artifact, get over it and move on. Arguing over > > policies intended to hoard the last remaining scraps on the bone is > > more the domain of the Condor or Jackal than civilized facilitators. > > > > Tony > > > > > > Tony, > > Neither David nor I support hoarding. I absolutely support returning portions > of the ARIN free pool to IANA for redistribution to other RIRs. > > However, what we want to avoid primarily with this policy is RIR policy > shopping and/or efforts by members of the other RIRs to essentially > circumvent their policies by effectively transferring space into those regions > outside of the control of those RIRs. RIR shopping A) is not a real problem because the result is not as disastrous as people speculate; B) is not going to be stopped by unenforceable policies; C) is an absurd necessity because the RIR memberships have forgotten that they are tasked as 'local facilitators' to -- distribute the resources -- on behalf of IANA. The RIRs are not resource tsar's, they are stewards. The entire concept of 'outside the control' has no place in this conversation. The only thing the RIRs need to be watching for is duplicate requests to fulfill the same deployment. If someone is a member of all 5 RIRs, does not acquire excess resource by using the same need in more than one request, and conforms to the policy where the request is made, it is not anyone's business how that gets deployed. > > This proposal applies to ASNs and IPv6 resources as well as IPv4. As it should, but there is still no justification for language that attempts to restrict where a resource is used. It is the height of hypocrisy to tell ARIN members that they cannot claim property rights over the assigned resources, yet ARIN has the ability to assert property rights by restricting where an asset gets used. The steward role requires ARIN to watch for duplicate requests to other RIRs for the same need, but the facilitator role requires them to -- actually distribute -- the resources. When the only intent of proposed language is to prevent distribution of resource because someone outside the ARIN region might benefit, it has to be called out and removed as counter to ARINs role as facilitator on behalf of IANA for the global resource. As long as a member makes a justified request, and is not duplicating that to get more from other RIRs, where that resource gets deployed is their issue alone. Besides, no matter what policy is put in place it is unenforceable because any resource that gets allocated can be moved later with a 'change of business requirements', and what justifies attempting reclamation? Unless you plan to make every operating network renumber all AS & address resources to be compliant with a regional restriction, there is no 'need' to do so for new deployments; meaning any such policy would not withstand a challenge. The only plausible justification for attempting a protectionist region restriction is hoarding to retain what little pool is left, in a hypocritical contortion of property rights. RIPE will exhaust their remaining IPv4 pool in a couple of months, so the pressure to do something will increase. Unfortunately people will more often do the irrational thing under pressure, and this protectionist language is already starting down that road. Raising the threat of 'shell companies subverting RIR control' only furthers the irrational behavior. Tony > > Owen From farmer at umn.edu Sat Jul 14 20:02:31 2012 From: farmer at umn.edu (David Farmer) Date: Sat, 14 Jul 2012 19:02:31 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> Message-ID: <50020897.7070602@umn.edu> On 7/14/12 17:32 CDT, Tony Hain wrote: > Owen DeLong wrote: ... >> However, what we want to avoid primarily with this policy is RIR policy >> shopping and/or efforts by members of the other RIRs to essentially >> circumvent their policies by effectively transferring space into those > regions >> outside of the control of those RIRs. > > RIR shopping A) is not a real problem because the result is not as > disastrous as people speculate; B) is not going to be stopped by > unenforceable policies; C) is an absurd necessity because the RIR > memberships have forgotten that they are tasked as 'local facilitators' to > -- distribute the resources -- on behalf of IANA. The RIRs are not > resource tsar's, they are stewards. The entire concept of 'outside the > control' has no place in this conversation. > > The only thing the RIRs need to be watching for is duplicate requests to > fulfill the same deployment. If someone is a member of all 5 RIRs, does not > acquire excess resource by using the same need in more than one request, and > conforms to the policy where the request is made, it is not anyone's > business how that gets deployed. I'm glad you agree we need to prevent duplicate and/or overlapping requests. So, your not asking for the "most liberal regional hierarchy" that was described in the Rationale, or at least you seem agree it needs some constraints on it at least. However, there are criteria that I'm told the global Internet community wants as well; 1. Regional independence and control of policy 2. Only justify the use of resources to the RIR you received them from using that RIRs policies In addition to; 3. Prevent duplicate and/or overlapping requests to multiple RIRs, in other words stewardship (that you identified) Tony, in your opinion are these all requirements? So when you combined those, one of the easiest solutions to identify, understand, and explain to others, is to regionalize. If you only receive resources from an RIR for use in that region you meet all of those requirements, this is essentially X.1. There are other solutions as well; Getting resource only from the region you are HQed in works too, this is essentially X.2. (Actually, ARIN-Prop-178 is a hybrid approach of the two, with fuzzy boundaries and some additional flexibility created with Incidental Use) Without some kind of regional hierarchy as a tool to control the overlap, wouldn't you need to justify your total global use of resources from all RIRs to each RIR every time you want additional resources? And if you do that by which polices does an RIR evaluate that global use its own, or the policies of the RIR that the resources were received? And, How do you resolve the conflicts? Personally, I'm willing to consider something like that and tried for several months to come up with language that had any hope to make that work, but couldn't. it always fail at least one of the three requirements above. Honestly, I never really got close either. Do you have ideas? Are any those requirements invalid? I'm not ignoring the rest of what you said, but I have to think about it more. But what I think your saying is there is another requirement; 4. No restriction on location of use And I'm not seeing a solution set for those four requirements. I believe we can have #1 & #2, with #3 or we can have #1 & #2, with #4, but I don't see how to have #1 & #2 with both #3 & #4. Honestly, I think splitting IANA up into the RIRs and giving them local policy control necessarily creates a requirement for restriction on location of use. Help me think of another way please. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jcurran at arin.net Sun Jul 15 07:03:46 2012 From: jcurran at arin.net (John Curran) Date: Sun, 15 Jul 2012 11:03:46 +0000 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <03a201cd61e3$1ae220b0$50a66210$@tndh.net> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> Message-ID: <9B271175-F073-497A-8793-5DC651E4B7B5@corp.arin.net> On Jul 14, 2012, at 1:07 PM, Tony Hain wrote: > Just a reminder that the address space is a global resource. ARIN is a > regional administrator to - facilitate - distribution, just like the other > 4. > ... > Rewind the clock to ~'96 when IANA handled all distribution, and there was > no 'this is mine' mentality. > ... > I still believe that the best course of action would be for the RIR holding > the largest pool to take on the role of IANA and do a monthly/quarterly > distribution through any RIR without the resources to meet its customer's > needs. Tony - Just to be clear on some factual references: In 1996, the distribution and management of number resources was predominantly handled by 3 organizations: RIPE NCC (for Europe), APNIC (for the Asia-Pacific Region), and by NSI for the rest-of-world (under the InterNIC cooperative agreement with NSF) Jon Postel, as the IANA, was involved in an overall policy role but not in the normal distribution process. This is all fairly well described in RFC 2050, which was published in 1996. In 1997, ARIN was established "to give the users of IP numbers ... a voice in the policies by which they are managed and allocated within the North American region." The number- related tasks of the InterNIC program were transferred to ARIN at its formation, and as a result the community in this region is indeed obligated to consider which policies are most appropriate for managing resources in the region, including the policies for assignments from the regional free pool. Regarding regional IPv4 availability pool management, I actually would have expected that these would be reduced as we approached run-out, and that each RIR would adopt smaller assignment windows and receive smaller regional IPv4 replenishments from the central IPv4 pool, with the net effect being a phasing out of the regional inventories as we neared the end. This would have resulted in an regional depletion which was more aligned and thus a concurrent global overall runout of IPv4. However, this was not to be, and there was strong support by the community in each region for instead allocating the final 5 /8 IPv4 blocks from the free pool to each RIR regardless of its regional inventory. Your call in 2007 for a "cooperative distribution policy" also did not gain traction ; it appears that it could have resulted in APNIC in turn issuing out of the regional IPv4 pools of ARIN, LACNIC, and AFRINIC (as each became the weekly source RIR) and also minimized the differences in regional inventories. As it is, we have ended up in a situation where there are dissimilar sized regional IPv4 inventories, and this has the potential for undesirable side- effects (such as attempts at "RIR shopping"). It is reasonable for the community in the ARIN region to consider this is as a policy matter, taking both the potential equity issues that arise as well as the transient nature of the problem into consideration. (As an aside, I'll also note this type of discussion may also be important in other regions, where the combination of relatively large local inventories and the prior runout in the APNIC, RIPE NCC, and ARIN regions will create some very interesting dynamics.) Thanks! /John John Curran President and CEO ARIN From farmer at umn.edu Sun Jul 15 13:32:03 2012 From: farmer at umn.edu (David Farmer) Date: Sun, 15 Jul 2012 12:32:03 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> Message-ID: <5002FE93.4000503@umn.edu> On 7/14/12 17:32 CDT, Tony Hain wrote: > Owen DeLong wrote: >> On Jul 14, 2012, at 10:07 AM, Tony Hain wrote: ... >> >> This proposal applies to ASNs and IPv6 resources as well as IPv4. > > As it should, but there is still no justification for language that attempts > to restrict where a resource is used. It is the height of hypocrisy to tell > ARIN members that they cannot claim property rights over the assigned > resources, yet ARIN has the ability to assert property rights by restricting > where an asset gets used. The steward role requires ARIN to watch for > duplicate requests to other RIRs for the same need, but the facilitator role > requires them to -- actually distribute -- the resources. When the only > intent of proposed language is to prevent distribution of resource because > someone outside the ARIN region might benefit, it has to be called out and > removed as counter to ARINs role as facilitator on behalf of IANA for the > global resource. > > As long as a member makes a justified request, and is not duplicating that > to get more from other RIRs, where that resource gets deployed is their > issue alone. Besides, no matter what policy is put in place it is > unenforceable because any resource that gets allocated can be moved later > with a 'change of business requirements', and what justifies attempting > reclamation? Unless you plan to make every operating network renumber all AS > & address resources to be compliant with a regional restriction, there is no > 'need' to do so for new deployments; meaning any such policy would not > withstand a challenge. The only plausible justification for attempting a > protectionist region restriction is hoarding to retain what little pool is > left, in a hypocritical contortion of property rights. > > RIPE will exhaust their remaining IPv4 pool in a couple of months, so the > pressure to do something will increase. Unfortunately people will more often > do the irrational thing under pressure, and this protectionist language is > already starting down that road. Raising the threat of 'shell companies > subverting RIR control' only furthers the irrational behavior. OK, I slept on it and have an idea. I need to reiterate the four requirements I discussed in my last email; 1. Regional independence and control of policy 2. Only justify the use of resources to the RIR you received them from using that RIRs policies 3. Prevent duplicate and/or overlapping requests to multiple RIRs, in other words provide stewardship 4. No restriction on location of use So, I'll float an idea. What if we allowed the requester to select between #2 or #4, allowing #1 and #3 to be meet in all cases. This way regionalization is simply a tool for simplifying justification of need and not necessarily a requirement to receive resources in all cases. This could be done with the following small rewrite of the first paragraph. ---- X. Regionalized Use of Resources Requests for number resources must meet the following criteria regarding regionalized use of resources for ARIN to only evaluate a request based on an organizations ARIN registered resources and according to ARIN policies, including any resource specific criteria. Otherwise, ARIN must evaluate a request based on an organizations total globally registered resources and only according to ARIN policies, including any resource specific criteria. ---- Is this workable? What do you think Tony? What does the rest of the community think? Would there need to be additional criteria defining how ARIN evaluates a organizations globally registered resource? Like I said I'm just floating an idea, I'm not even sure I like it yet. Let me know what you think. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Sun Jul 15 15:23:48 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 15 Jul 2012 12:23:48 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <5002FE93.4000503@umn.edu> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> Message-ID: <45E3BEAA-1256-46EC-B96D-E37DD3003AA1@delong.com> That would basically completely enable policy shopping and/or fee shopping to select whichever of the 5 RIRs you wanted regardless of location. I cannot support that. Owen On Jul 15, 2012, at 10:32 AM, David Farmer wrote: > > > On 7/14/12 17:32 CDT, Tony Hain wrote: >> Owen DeLong wrote: >>> On Jul 14, 2012, at 10:07 AM, Tony Hain wrote: > ... >>> >>> This proposal applies to ASNs and IPv6 resources as well as IPv4. >> >> As it should, but there is still no justification for language that attempts >> to restrict where a resource is used. It is the height of hypocrisy to tell >> ARIN members that they cannot claim property rights over the assigned >> resources, yet ARIN has the ability to assert property rights by restricting >> where an asset gets used. The steward role requires ARIN to watch for >> duplicate requests to other RIRs for the same need, but the facilitator role >> requires them to -- actually distribute -- the resources. When the only >> intent of proposed language is to prevent distribution of resource because >> someone outside the ARIN region might benefit, it has to be called out and >> removed as counter to ARINs role as facilitator on behalf of IANA for the >> global resource. >> >> As long as a member makes a justified request, and is not duplicating that >> to get more from other RIRs, where that resource gets deployed is their >> issue alone. Besides, no matter what policy is put in place it is >> unenforceable because any resource that gets allocated can be moved later >> with a 'change of business requirements', and what justifies attempting >> reclamation? Unless you plan to make every operating network renumber all AS >> & address resources to be compliant with a regional restriction, there is no >> 'need' to do so for new deployments; meaning any such policy would not >> withstand a challenge. The only plausible justification for attempting a >> protectionist region restriction is hoarding to retain what little pool is >> left, in a hypocritical contortion of property rights. >> >> RIPE will exhaust their remaining IPv4 pool in a couple of months, so the >> pressure to do something will increase. Unfortunately people will more often >> do the irrational thing under pressure, and this protectionist language is >> already starting down that road. Raising the threat of 'shell companies >> subverting RIR control' only furthers the irrational behavior. > > OK, I slept on it and have an idea. > > I need to reiterate the four requirements I discussed in my last email; > > 1. Regional independence and control of policy > > 2. Only justify the use of resources to the RIR you received them from using that RIRs policies > > 3. Prevent duplicate and/or overlapping requests to multiple RIRs, in other words provide stewardship > > 4. No restriction on location of use > > So, I'll float an idea. What if we allowed the requester to select between #2 or #4, allowing #1 and #3 to be meet in all cases. This way regionalization is simply a tool for simplifying justification of need and not necessarily a requirement to receive resources in all cases. > > This could be done with the following small rewrite of the first paragraph. > > ---- > > X. Regionalized Use of Resources > > Requests for number resources must meet the following criteria regarding regionalized use of resources for ARIN to only evaluate a request based on an organizations ARIN registered resources and according to ARIN policies, including any resource specific criteria. Otherwise, ARIN must evaluate a request based on an organizations total globally registered resources and only according to ARIN policies, including any resource specific criteria. > > ---- > > Is this workable? What do you think Tony? What does the rest of the community think? Would there need to be additional criteria defining how ARIN evaluates a organizations globally registered resource? > > Like I said I'm just floating an idea, I'm not even sure I like it yet. > > Let me know what you think. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > From matthew at matthew.at Sun Jul 15 15:28:20 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 15 Jul 2012 12:28:20 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <45E3BEAA-1256-46EC-B96D-E37DD3003AA1@delong.com> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> <45E3BEAA-1256-46EC-B96D-E37DD3003AA1@delong.com> Message-ID: <500319D4.2020208@matthew.at> On 7/15/2012 12:23 PM, Owen DeLong wrote: > That would basically completely enable policy shopping and/or fee shopping to select whichever of the 5 RIRs you wanted regardless of location. Maybe the 5 RIRs shouldn't have different policies. Matthew Kaufman From mysidia at gmail.com Sun Jul 15 15:38:18 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 15 Jul 2012 14:38:18 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <500319D4.2020208@matthew.at> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> <45E3BEAA-1256-46EC-B96D-E37DD3003AA1@delong.com> <500319D4.2020208@matthew.at> Message-ID: On 7/15/12, Matthew Kaufman wrote: > On 7/15/2012 12:23 PM, Owen DeLong wrote: >> That would basically completely enable policy shopping and/or fee shopping >> to select whichever of the 5 RIRs you wanted regardless of location. > Maybe the 5 RIRs shouldn't have different policies. Maybe there shouldn't be any RIRs. Why would we need 5 RIRs with the same policies? Anyone who comes to ARIN to request resources, should have to adhere to the same policy and justified needs requirements for ALL resources they have been assigned from any source, regardless of where the resources are assigned or where the resources are going to be used. -- -JH From farmer at umn.edu Sun Jul 15 16:03:07 2012 From: farmer at umn.edu (David Farmer) Date: Sun, 15 Jul 2012 15:03:07 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <03a201cd61e3$1ae220b0$50a66210$@tndh.net> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> Message-ID: <500321FB.6080207@umn.edu> On 7/14/12 12:07 CDT, Tony Hain wrote: > Owen DeLong wrote: >> ... >> >> Do you think that an ISP from out of region should be allowed to set up a >> small shell company in the US and then obtain unlimited resources from > ARIN >> to use in their operations elsewhere in the world? >>> ... > > Just a reminder that the address space is a global resource. ARIN is a > regional administrator to - facilitate - distribution, just like the other > 4. It was not set up to act as a body that hoards everything it can get its > hands on. > > Rewind the clock to ~'96 when IANA handled all distribution, and there was > no 'this is mine' mentality. Seriously, 2 year olds in the sandbox do a > better job of resource sharing than what we are seeing in the wind-down of > the IPv4 pool. > > I still believe that the best course of action would be for the RIR holding > the largest pool to take on the role of IANA and do a monthly/quarterly > distribution through any RIR without the resources to meet its customer's > needs. This avoids the problem of shell companies in all regions, and the > associated short-term bubble staffing demands to review requests; as well as > depleting the remaining free pool in an expeditious manner, which avoids > absurd distortions in whatever market emerges. > > IPv4 is a historical artifact, get over it and move on. Arguing over > policies intended to hoard the last remaining scraps on the bone is more the > domain of the Condor or Jackal than civilized facilitators. Tony, Just to be clear, my personal motivations for tackling this issue is IPv6. Many people are only just starting their IPv6 implementations. The ambiguity and complete lack of clear policy statements on how the management of resources across multiple regions is suppose to work creates an unacceptable danger that people may implement IPv6 using separate unaggregatable prefixes from multiple RIRs. When they may be willing to use a single globally aggregated prefix, if the policy wasn't so ambiguous on the issue. It just so happens that most people's implementation of IPv6 coincides with IPv4 run-out, this is unfortunate, but a very typical human response of procrastination. Please don't take that as harsh criticism, I'm a master procrastinator. I just haven't procrastinated on IPv6, which is extremely atypical for me personally, I guess I just found IPv6 to be cool and worth my effort. :) So, while I tend to agree the "IPv4 is a historical artifact" and we need to get over it. I'm not naive enough to think we can touch this issue without dealing with IPv4, its just the way things are. But, all along I've asked myself first and foremost what do we need for IPv6 going forward, and only considering IPv4 after that. To me it is completely unacceptable that something as important as how resources are managed across multiple regions is left to an ambiguous statement like the following. ---- 2.2. Regional Internet Registry (RIR) Regional Internet Registries (RIRs) are established and authorized by respective regional communities, and recognized by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions. ---- As I've said about other issues we need to find middle ground here and find something workable for everyone. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From mysidia at gmail.com Sun Jul 15 16:22:46 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 15 Jul 2012 15:22:46 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <500321FB.6080207@umn.edu> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <500321FB.6080207@umn.edu> Message-ID: On 7/15/12, David Farmer wrote: > creates an unacceptable danger that people may implement IPv6 using > separate unaggregatable prefixes from multiple RIRs. When they may be Prefixes from other RIRs are aggregable along the Geographical address assignment hierarchy lines. Aggregation of all prefixes to outside RIR region X to one route for external Region X. "One global prefix" is in conflict with better efficiency achieved through that method. -- -JH From owen at delong.com Sun Jul 15 17:32:15 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 15 Jul 2012 14:32:15 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <500321FB.6080207@umn.edu> Message-ID: On Jul 15, 2012, at 1:22 PM, Jimmy Hess wrote: > On 7/15/12, David Farmer wrote: >> creates an unacceptable danger that people may implement IPv6 using >> separate unaggregatable prefixes from multiple RIRs. When they may be > > Prefixes from other RIRs are aggregable along the Geographical > address assignment hierarchy lines. > > Aggregation of all prefixes to outside RIR region X to one route > for external Region X. > > "One global prefix" is in conflict with better efficiency achieved > through that method. > > -- > -JH That's not universally true. If you operate a highly efficient backbone network, you actually get greatest efficiency from accepting your traffic on a hot potato basis and controlling it across your own network as soon as possible. Advertising a single global prefix facilitates that quite well. The backbone operator should have the choice and this proposal accomplishes exactly that... Either number your global network out of a single RIR (mostly) or number your network out of each region (mostly) with room for some flexibility to accommodate the differences between theoretical optimizations and real world deployments. Owen From alh-ietf at tndh.net Mon Jul 16 14:40:03 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 16 Jul 2012 11:40:03 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <5002FE93.4000503@umn.edu> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> Message-ID: <04a101cd6382$6b84dc60$428e9520$@tndh.net> David Farmer wrote: > On 7/14/12 17:32 CDT, Tony Hain wrote: > > Owen DeLong wrote: > >> On Jul 14, 2012, at 10:07 AM, Tony Hain wrote: > ... > >> > >> This proposal applies to ASNs and IPv6 resources as well as IPv4. > > > > As it should, but there is still no justification for language that > > attempts to restrict where a resource is used. It is the height of > > hypocrisy to tell ARIN members that they cannot claim property rights > > over the assigned resources, yet ARIN has the ability to assert > > property rights by restricting where an asset gets used. The steward > > role requires ARIN to watch for duplicate requests to other RIRs for > > the same need, but the facilitator role requires them to -- actually > > distribute -- the resources. When the only intent of proposed language > > is to prevent distribution of resource because someone outside the > > ARIN region might benefit, it has to be called out and removed as > > counter to ARINs role as facilitator on behalf of IANA for the global > resource. > > > > As long as a member makes a justified request, and is not duplicating > > that to get more from other RIRs, where that resource gets deployed is > > their issue alone. Besides, no matter what policy is put in place it > > is unenforceable because any resource that gets allocated can be moved > > later with a 'change of business requirements', and what justifies > > attempting reclamation? Unless you plan to make every operating > > network renumber all AS & address resources to be compliant with a > > regional restriction, there is no 'need' to do so for new deployments; > > meaning any such policy would not withstand a challenge. The only > > plausible justification for attempting a protectionist region > > restriction is hoarding to retain what little pool is left, in a hypocritical > contortion of property rights. > > > > RIPE will exhaust their remaining IPv4 pool in a couple of months, so > > the pressure to do something will increase. Unfortunately people will > > more often do the irrational thing under pressure, and this > > protectionist language is already starting down that road. Raising the > > threat of 'shell companies subverting RIR control' only furthers the > irrational behavior. > > OK, I slept on it and have an idea. > > I need to reiterate the four requirements I discussed in my last email; > > 1. Regional independence and control of policy > > 2. Only justify the use of resources to the RIR you received them from using > that RIRs policies I mis-read that one the first time. You should only need to justify the resources you are requesting from the RIR being asked. > > 3. Prevent duplicate and/or overlapping requests to multiple RIRs, in other > words provide stewardship > > 4. No restriction on location of use > > So, I'll float an idea. What if we allowed the requester to select between #2 > or #4, allowing #1 and #3 to be meet in all cases. This way regionalization is > simply a tool for simplifying justification of need and not necessarily a > requirement to receive resources in all cases. > > This could be done with the following small rewrite of the first paragraph. > > ---- > > X. Regionalized Use of Resources > > Requests for number resources must meet the following criteria regarding > regionalized use of resources for ARIN to only evaluate a request based on > an organizations ARIN registered resources and according to ARIN policies, > including any resource specific criteria. Otherwise, ARIN must evaluate a > request based on an organizations total globally registered resources and > only according to ARIN policies, including any resource specific criteria. > > ---- > > Is this workable? What do you think Tony? What does the rest of the > community think? Would there need to be additional criteria defining how > ARIN evaluates a organizations globally registered resource? I think I am saying drop everything up to 'Otherwise'. Where the new resource is being used is irrelevant. > > Like I said I'm just floating an idea, I'm not even sure I like it yet. > > Let me know what you think. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== From alh-ietf at tndh.net Mon Jul 16 14:35:19 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 16 Jul 2012 11:35:19 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <50020897.7070602@umn.edu> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <50020897.7070602@umn.edu> Message-ID: <04a001cd6381$c1d27a60$45776f20$@tndh.net> David Farmer wrote: > > ... > > The only thing the RIRs need to be watching for is duplicate requests > > to fulfill the same deployment. If someone is a member of all 5 RIRs, > > does not acquire excess resource by using the same need in more than > > one request, and conforms to the policy where the request is made, it > > is not anyone's business how that gets deployed. > > I'm glad you agree we need to prevent duplicate and/or overlapping > requests. So, your not asking for the "most liberal regional hierarchy" > that was described in the Rationale, or at least you seem agree it needs some > constraints on it at least. > > However, there are criteria that I'm told the global Internet community > wants as well; > > 1. Regional independence and control of policy > > 2. Only justify the use of resources to the RIR you received them from using > that RIRs policies > > In addition to; > > 3. Prevent duplicate and/or overlapping requests to multiple RIRs, in other > words stewardship (that you identified) > > Tony, in your opinion are these all requirements? I believe those are the requirements, and are completely compatible with what I said. > > So when you combined those, one of the easiest solutions to identify, > understand, and explain to others, is to regionalize. > > If you only receive resources from an RIR for use in that region you meet all > of those requirements, this is essentially X.1. There are other solutions as > well; Getting resource only from the region you are HQed in works too, this is > essentially X.2. (Actually, ARIN-Prop-178 is a hybrid approach of the two, with > fuzzy boundaries and some additional flexibility created with Incidental Use) X.3 fundamentally invalidates any 'need' for either X.1 or X.2. > > Without some kind of regional hierarchy as a tool to control the overlap, > wouldn't you need to justify your total global use of resources from all RIRs > to each RIR every time you want additional resources? No, you justify global use of resources from all RIRs to the one you are making the current request from. > And if you do that by > which polices does an RIR evaluate that global use its own, or the policies of > the RIR that the resources were received? The RIR evaluates based on its own policies. > And, How do you resolve the conflicts? The requestor has to meet the policies of the RIR being asked. How they justified resources in the past is not an issue. The only thing being evaluated is 'are the current resources being deployed according to the policy requirements of the RIR being asked for new resources?' > > Personally, I'm willing to consider something like that and tried for several > months to come up with language that had any hope to make that work, but > couldn't. it always fail at least one of the three > requirements above. Honestly, I never really got close either. Do you > have ideas? Are any those requirements invalid? > > I'm not ignoring the rest of what you said, but I have to think about it more. > > But what I think your saying is there is another requirement; > > 4. No restriction on location of use > > And I'm not seeing a solution set for those four requirements. I believe we > can have #1 & #2, with #3 or we can have #1 & #2, with #4, but I don't see > how to have #1 & #2 with both #3 & #4. Honestly, I think splitting IANA up > into the RIRs and giving them local policy control necessarily creates a > requirement for restriction on location of use. No, location is a non-issue. Any requestor has resources in deployment on a global basis. Any request they make for additional resources has to meet the policies of the RIR they are requesting from. The regionalization has more to do with aligning administrative procedures with social & international norms than it does with where the resources are deployed. Tony > > Help me think of another way please. > > Thanks > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > From alh-ietf at tndh.net Mon Jul 16 14:48:32 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 16 Jul 2012 11:48:32 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <45E3BEAA-1256-46EC-B96D-E37DD3003AA1@delong.com> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> <45E3BEAA-1256-46EC-B96D-E37DD3003AA1@delong.com> Message-ID: <04a201cd6383$9ade7bf0$d09b73d0$@tndh.net> Owen DeLong wrote: > > That would basically completely enable policy shopping and/or fee shopping > to select whichever of the 5 RIRs you wanted regardless of location. > > I cannot support that. Since when is competition a bad thing? As long as someone is a member, they are entitled to the resources just like every other member. As long as they are not doing duplicate requests for the same deployment, and they are meeting policy, what does it matter where the deployment happens? Any smart member of all 5 registries would realize which policies they do or do not meet, and would only make one request any way. Bottom line; you can't say regional use restrictions are an operational requirement without redeploying all past discrepancies. This means any attempt at regional use restrictions going forward is simply based on hoarding the remaining pool. Tony > > Owen > > On Jul 15, 2012, at 10:32 AM, David Farmer wrote: > > > > > > > On 7/14/12 17:32 CDT, Tony Hain wrote: > >> Owen DeLong wrote: > >>> On Jul 14, 2012, at 10:07 AM, Tony Hain wrote: > > ... > >>> > >>> This proposal applies to ASNs and IPv6 resources as well as IPv4. > >> > >> As it should, but there is still no justification for language that > >> attempts to restrict where a resource is used. It is the height of > >> hypocrisy to tell ARIN members that they cannot claim property rights > >> over the assigned resources, yet ARIN has the ability to assert > >> property rights by restricting where an asset gets used. The steward > >> role requires ARIN to watch for duplicate requests to other RIRs for > >> the same need, but the facilitator role requires them to -- actually > >> distribute -- the resources. When the only intent of proposed > >> language is to prevent distribution of resource because someone > >> outside the ARIN region might benefit, it has to be called out and > >> removed as counter to ARINs role as facilitator on behalf of IANA for the > global resource. > >> > >> As long as a member makes a justified request, and is not duplicating > >> that to get more from other RIRs, where that resource gets deployed > >> is their issue alone. Besides, no matter what policy is put in place > >> it is unenforceable because any resource that gets allocated can be > >> moved later with a 'change of business requirements', and what > >> justifies attempting reclamation? Unless you plan to make every > >> operating network renumber all AS & address resources to be compliant > >> with a regional restriction, there is no 'need' to do so for new > >> deployments; meaning any such policy would not withstand a challenge. > >> The only plausible justification for attempting a protectionist > >> region restriction is hoarding to retain what little pool is left, in a > hypocritical contortion of property rights. > >> > >> RIPE will exhaust their remaining IPv4 pool in a couple of months, > >> so the pressure to do something will increase. Unfortunately people > >> will more often do the irrational thing under pressure, and this > >> protectionist language is already starting down that road. Raising > >> the threat of 'shell companies subverting RIR control' only furthers the > irrational behavior. > > > > OK, I slept on it and have an idea. > > > > I need to reiterate the four requirements I discussed in my last > > email; > > > > 1. Regional independence and control of policy > > > > 2. Only justify the use of resources to the RIR you received them from > > using that RIRs policies > > > > 3. Prevent duplicate and/or overlapping requests to multiple RIRs, in > > other words provide stewardship > > > > 4. No restriction on location of use > > > > So, I'll float an idea. What if we allowed the requester to select between > #2 or #4, allowing #1 and #3 to be meet in all cases. This way regionalization > is simply a tool for simplifying justification of need and not necessarily a > requirement to receive resources in all cases. > > > > This could be done with the following small rewrite of the first paragraph. > > > > ---- > > > > X. Regionalized Use of Resources > > > > Requests for number resources must meet the following criteria regarding > regionalized use of resources for ARIN to only evaluate a request based on > an organizations ARIN registered resources and according to ARIN policies, > including any resource specific criteria. Otherwise, ARIN must evaluate a > request based on an organizations total globally registered resources and > only according to ARIN policies, including any resource specific criteria. > > > > ---- > > > > Is this workable? What do you think Tony? What does the rest of the > community think? Would there need to be additional criteria defining how > ARIN evaluates a organizations globally registered resource? > > > > Like I said I'm just floating an idea, I'm not even sure I like it yet. > > > > Let me know what you think. > > > > -- > > =============================================== > > David Farmer Email:farmer at umn.edu > > Networking & Telecommunication Services Office of Information > > Technology > > University of Minnesota > > 2218 University Ave SE Phone: 612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > > =============================================== > > From alh-ietf at tndh.net Mon Jul 16 14:53:05 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 16 Jul 2012 11:53:05 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> <45E3BEAA-1256-46EC-B96D-E37DD3003AA1@delong.com> <500319D4.2020208@matthew.at> Message-ID: <04a301cd6384$3d239f30$b76add90$@tndh.net> Jimmy Hess wrote: > On 7/15/12, Matthew Kaufman wrote: > > On 7/15/2012 12:23 PM, Owen DeLong wrote: > >> That would basically completely enable policy shopping and/or fee > >> shopping to select whichever of the 5 RIRs you wanted regardless of > location. > > Maybe the 5 RIRs shouldn't have different policies. > > Maybe there shouldn't be any RIRs. > Why would we need 5 RIRs with the same policies? The entire point of splitting the load out from under IANA was to align distribution policies with social & international norms, which do differ in each region. It was not to set up protectionist barriers to entry, because at the root the resources are for global use. > > Anyone who comes to ARIN to request resources, should have to adhere to > the same policy and justified needs requirements for ALL resources they > have been assigned from any source, regardless of where the resources are > assigned or where the resources are going to be used. This is the point I have been trying to make, though you did it much more succinctly. Tony > > -- > -JH > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From alh-ietf at tndh.net Mon Jul 16 14:59:45 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 16 Jul 2012 11:59:45 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <500321FB.6080207@umn.edu> Message-ID: <04a401cd6385$2b941e60$82bc5b20$@tndh.net> Owen DeLong wrote: > On Jul 15, 2012, at 1:22 PM, Jimmy Hess wrote: > > > On 7/15/12, David Farmer wrote: > >> creates an unacceptable danger that people may implement IPv6 using > >> separate unaggregatable prefixes from multiple RIRs. When they may > >> be > > > > Prefixes from other RIRs are aggregable along the Geographical address > > assignment hierarchy lines. > > > > Aggregation of all prefixes to outside RIR region X to one route > > for external Region X. > > > > "One global prefix" is in conflict with better efficiency achieved > > through that method. > > > > -- > > -JH > > That's not universally true. If you operate a highly efficient backbone > network, you actually get greatest efficiency from accepting your traffic on a > hot potato basis and controlling it across your own network as soon as > possible. Advertising a single global prefix facilitates that quite well. This highlights why it is insane to restrict a resource to 'only for use within the allocating region'. > > The backbone operator should have the choice and this proposal > accomplishes exactly that... Either number your global network out of a > single RIR (mostly) or number your network out of each region (mostly) with > room for some flexibility to accommodate the differences between > theoretical optimizations and real world deployments. And the 'flexibility' creates ambiguity, which in turn leads to conflict, which in turn makes the proposed language unenforceable. Simplify and make the requirement 'must justify existing global resource use against policy of the RIR being asked'. Tony > > Owen From owen at delong.com Mon Jul 16 16:47:29 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Jul 2012 13:47:29 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <04a401cd6385$2b941e60$82bc5b20$@tndh.net> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <500321FB.6080207@umn.edu> <04a401cd6385$2b941e60$82bc5b20$@tndh.net> Message-ID: <9D8E118E-86BC-4E6F-8AE8-51735745DB5F@delong.com> Sent from my iPad On Jul 16, 2012, at 11:59 AM, "Tony Hain" wrote: > Owen DeLong wrote: >> On Jul 15, 2012, at 1:22 PM, Jimmy Hess wrote: >> >>> On 7/15/12, David Farmer wrote: >>>> creates an unacceptable danger that people may implement IPv6 using >>>> separate unaggregatable prefixes from multiple RIRs. When they may >>>> be >>> >>> Prefixes from other RIRs are aggregable along the Geographical address >>> assignment hierarchy lines. >>> >>> Aggregation of all prefixes to outside RIR region X to one route >>> for external Region X. >>> >>> "One global prefix" is in conflict with better efficiency achieved >>> through that method. >>> >>> -- >>> -JH >> >> That's not universally true. If you operate a highly efficient backbone >> network, you actually get greatest efficiency from accepting your traffic > on a >> hot potato basis and controlling it across your own network as soon as >> possible. Advertising a single global prefix facilitates that quite well. > > This highlights why it is insane to restrict a resource to 'only for use > within the allocating region'. > Which the proposed policy does not do. >> >> The backbone operator should have the choice and this proposal >> accomplishes exactly that... Either number your global network out of a >> single RIR (mostly) or number your network out of each region (mostly) > with >> room for some flexibility to accommodate the differences between >> theoretical optimizations and real world deployments. > > And the 'flexibility' creates ambiguity, which in turn leads to conflict, > which in turn makes the proposed language unenforceable. Simplify and make > the requirement 'must justify existing global resource use against policy of > the RIR being asked'. > I think it is time to agree to disagree on this point. Owen > Tony > >> >> Owen From farmer at umn.edu Mon Jul 16 21:03:31 2012 From: farmer at umn.edu (David Farmer) Date: Mon, 16 Jul 2012 20:03:31 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <04a101cd6382$6b84dc60$428e9520$@tndh.net> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> <04a101cd6382$6b84dc60$428e9520$@tndh.net> Message-ID: <5004B9E3.9080305@umn.edu> On 7/16/12 13:40 CDT, Tony Hain wrote: > David Farmer wrote: >> On 7/14/12 17:32 CDT, Tony Hain wrote: >>> Owen DeLong wrote: .... >> OK, I slept on it and have an idea. >> >> I need to reiterate the four requirements I discussed in my last email; >> >> 1. Regional independence and control of policy >> >> 2. Only justify the use of resources to the RIR you received them from using >> that RIRs policies > > I mis-read that one the first time. You should only need to justify the > resources you are requesting from the RIR being asked. I'm confused this seems to conflict with below; >> 3. Prevent duplicate and/or overlapping requests to multiple RIRs, in > other >> words provide stewardship >> >> 4. No restriction on location of use >> >> So, I'll float an idea. What if we allowed the requester to select between #2 >> or #4, allowing #1 and #3 to be meet in all cases. This way regionalization is >> simply a tool for simplifying justification of need and not necessarily a >> requirement to receive resources in all cases. >> >> This could be done with the following small rewrite of the first paragraph. >> >> ---- >> >> X. Regionalized Use of Resources >> >> Requests for number resources must meet the following criteria regarding >> regionalized use of resources for ARIN to only evaluate a request based on >> an organizations ARIN registered resources and according to ARIN policies, >> including any resource specific criteria. Otherwise, ARIN must evaluate a >> request based on an organizations total globally registered resources and >> only according to ARIN policies, including any resource specific criteria. >> >> ---- >> >> Is this workable? What do you think Tony? What does the rest of the >> community think? Would there need to be additional criteria defining how >> ARIN evaluates a organizations globally registered resource? > > I think I am saying drop everything up to 'Otherwise'. Where the new > resource is being used is irrelevant. So, some org in the APNIC region and has always received their resources from APNIC, but can can't get an IPv4 any more. They want to get IPv4 from ARIN, do they have to demonstrate that they have utilized their APNIC resources according to ARIN policy before getting resources from ARIN? If yes then that violates requirement #2 and seems to violate your response above. But if here you seem to be saying that ARIN should evaluate all their global resources. Deleting everything up to and including the "Otherwise," you are left with. "ARIN must evaluate a request based on an organizations total globally registered resources and only according to ARIN policies, including any resource specific criteria." I read this as saying that ARIN should evaluate all resources regardless of which RIR issued them. Is that what you are saying? -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From alh-ietf at tndh.net Tue Jul 17 11:59:16 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 17 Jul 2012 08:59:16 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <5004B9E3.9080305@umn.edu> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> <04a101cd6382$6b84dc60$428e9520$@tndh.net> <5004B9E3.9080305@umn.edu> Message-ID: <057001cd6435$1f816370$5e842a50$@tndh.net> David Farmer wrote: > On 7/16/12 13:40 CDT, Tony Hain wrote: > > David Farmer wrote: > >> On 7/14/12 17:32 CDT, Tony Hain wrote: > >>> Owen DeLong wrote: > .... > >> OK, I slept on it and have an idea. > >> > >> I need to reiterate the four requirements I discussed in my last > >> email; > >> > >> 1. Regional independence and control of policy > >> > >> 2. Only justify the use of resources to the RIR you received them > >> from using that RIRs policies > > > > I mis-read that one the first time. You should only need to justify > > the resources you are requesting from the RIR being asked. > > I'm confused this seems to conflict with below; > > >> 3. Prevent duplicate and/or overlapping requests to multiple RIRs, in > > other > >> words provide stewardship > >> > >> 4. No restriction on location of use > >> > >> So, I'll float an idea. What if we allowed the requester to select > >> between #2 or #4, allowing #1 and #3 to be meet in all cases. This > >> way regionalization is simply a tool for simplifying justification of > >> need and not necessarily a requirement to receive resources in all cases. > >> > >> This could be done with the following small rewrite of the first paragraph. > >> > >> ---- > >> > >> X. Regionalized Use of Resources > >> > >> Requests for number resources must meet the following criteria > >> regarding regionalized use of resources for ARIN to only evaluate a > >> request based on an organizations ARIN registered resources and > >> according to ARIN policies, including any resource specific criteria. > >> Otherwise, ARIN must evaluate a request based on an organizations > >> total globally registered resources and only according to ARIN policies, > including any resource specific criteria. > >> > >> ---- > >> > >> Is this workable? What do you think Tony? What does the rest of the > >> community think? Would there need to be additional criteria defining > >> how ARIN evaluates a organizations globally registered resource? > > > > I think I am saying drop everything up to 'Otherwise'. Where the new > > resource is being used is irrelevant. > > So, some org in the APNIC region and has always received their resources > from APNIC, but can can't get an IPv4 any more. > > They want to get IPv4 from ARIN, do they have to demonstrate that they > have utilized their APNIC resources according to ARIN policy before getting > resources from ARIN? Yes, including any slow-start for new members. > > If yes then that violates requirement #2 and seems to violate your response > above. The wording of #2 is confusing enough that I misread it the first time, so my flipping responses might be even more confusing. The past is the past, and therefore irrelevant. Maybe this simplifies: A new request is on the table at one-and-only-one RIR, so that RIR has to use its current policy to evaluate the organizations global resource deployment. > > But if here you seem to be saying that ARIN should evaluate all their global > resources. > > Deleting everything up to and including the "Otherwise," you are left with. > > "ARIN must evaluate a request based on an organizations total globally > registered resources and only according to ARIN policies, including any > resource specific criteria." > > I read this as saying that ARIN should evaluate all resources regardless of > which RIR issued them. > > Is that what you are saying? Yes. The point is that everyone has to meet current ARIN policies when making a new request. Where past resources were acquired, or where they are deployed globally are irrelevant, as long as the requestor is doing 'proper stewardship'; where 'proper' is defined by current criterion established at the RIR they are asking to provide more. To me, this is the only way to avoid policy conflicts, and deal with pre-RIR resources fairly. If the RIR system had not been created, this is exactly what they would have to do at IANA, so why should the RIR mechanism be any different? Tony > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== From alh-ietf at tndh.net Tue Jul 17 12:15:21 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 17 Jul 2012 09:15:21 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <9D8E118E-86BC-4E6F-8AE8-51735745DB5F@delong.com> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <500321FB.6080207@umn.edu> <04a401cd6385$2b941e60$82bc5b20$@tndh.net> <9D8E118E-86BC-4E6F-8AE8-51735745DB5F@delong.com> Message-ID: <057a01cd6437$5f328e20$1d97aa60$@tndh.net> Owen DeLong wrote: > Sent from my iPad > > On Jul 16, 2012, at 11:59 AM, "Tony Hain" wrote: > > > Owen DeLong wrote: > >> On Jul 15, 2012, at 1:22 PM, Jimmy Hess wrote: > >> > >>> On 7/15/12, David Farmer wrote: > >>>> creates an unacceptable danger that people may implement IPv6 using > >>>> separate unaggregatable prefixes from multiple RIRs. When they may > >>>> be > >>> > >>> Prefixes from other RIRs are aggregable along the Geographical > >>> address assignment hierarchy lines. > >>> > >>> Aggregation of all prefixes to outside RIR region X to one route > >>> for external Region X. > >>> > >>> "One global prefix" is in conflict with better efficiency achieved > >>> through that method. > >>> > >>> -- > >>> -JH > >> > >> That's not universally true. If you operate a highly efficient > >> backbone network, you actually get greatest efficiency from accepting > >> your traffic > > on a > >> hot potato basis and controlling it across your own network as soon > >> as possible. Advertising a single global prefix facilitates that quite well. > > > > This highlights why it is insane to restrict a resource to 'only for > > use within the allocating region'. > > > > Which the proposed policy does not do. Running a global transit network as a single prefix is not 'incidental use'. > > >> > >> The backbone operator should have the choice and this proposal > >> accomplishes exactly that... Either number your global network out of > >> a single RIR (mostly) or number your network out of each region > >> (mostly) > > with > >> room for some flexibility to accommodate the differences between > >> theoretical optimizations and real world deployments. > > > > And the 'flexibility' creates ambiguity, which in turn leads to > > conflict, which in turn makes the proposed language unenforceable. > > Simplify and make the requirement 'must justify existing global > > resource use against policy of the RIR being asked'. > > > > I think it is time to agree to disagree on this point. Possibly, but consider the ambiguity of this case: A corporate entity has its headquarters in the ARIN region. It therefore qualifies under the proposal X2 for using ARIN resources on a global basis. BUT --- that entity is actually a subsidiary of a multi-national conglomerate with headquarters elsewhere. It is still a legally recognized entity with a separate name, headquartered in the ARIN region, so you can't argue that it doesn't qualify under X2 just because its parent happens to be elsewhere. So exactly what problem does the proposed policy exactly solve? Your comment on 7/13 implies that you expect this proposal to prevent a shell company from moving resources outside the region, but there is no legal mechanism for ARIN to enforce that. You either have to force all resources for everyone to be regionally constrained, or there is no enforceable constraint. Tony > > Owen > > > Tony > > > >> > >> Owen From jrhett at netconsonance.com Tue Jul 17 13:49:21 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 17 Jul 2012 10:49:21 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <500321FB.6080207@umn.edu> Message-ID: <52149845-86E7-4337-B4F5-2F242E3BA75C@netconsonance.com> I not only don't support this proposal, but I'll bring a heavy heavy hammer to try and destroy it if it goes farther. This is the worst kind of policy. I believe that this entire discussion falls under what in another community is called "fandom wank", mostly a "I wouldn't have designed it this way!" discussion. There are other RIRs. They have their own policies, and those policies are voted in by their members. I strongly disagree that ARIN should do anything at all that would allow a member to use ARIN IP space in their region to circumvent their policies. Absolutely nothing anyone says on this list is going to change my mind. I don't care if they eat babies at that RIR, it's a policy decision there and it's not our job to undermine it. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Jul 17 17:10:50 2012 From: farmer at umn.edu (David Farmer) Date: Tue, 17 Jul 2012 16:10:50 -0500 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <057001cd6435$1f816370$5e842a50$@tndh.net> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> <04a101cd6382$6b84dc60$428e9520$@tndh.net> <5004B9E3.9080305@umn.edu> <057001cd6435$1f816370$5e842a50$@tndh.net> Message-ID: <5005D4DA.3040202@umn.edu> On 7/17/12 10:59 CDT, Tony Hain wrote: > David Farmer wrote: .... >> "ARIN must evaluate a request based on an organizations total globally >> registered resources and only according to ARIN policies, including any >> resource specific criteria." >> >> I read this as saying that ARIN should evaluate all resources regardless of >> which RIR issued them. >> >> Is that what you are saying? > > Yes. The point is that everyone has to meet current ARIN policies when > making a new request. > > Where past resources were acquired, or where they are deployed globally are > irrelevant, as long as the requestor is doing 'proper stewardship'; where > 'proper' is defined by current criterion established at the RIR they are > asking to provide more. To me, this is the only way to avoid policy > conflicts, and deal with pre-RIR resources fairly. If the RIR system had not > been created, this is exactly what they would have to do at IANA, so why > should the RIR mechanism be any different? OK, I think I get what your saying now, thanks for your patience in helping me work through it. I believe, that essentially says you can only have your global future demand or allocation window from one RIR at a time and you can't get anything from another RIR until you have used up you current allocation window to the extent required by the next RIR you decide to get resources from. That works for fine for IPv6 with the single global aggregate model that X.2 is going after. However, there are others that wish to get IPv6 resources and receive an allocation window from each RIR to aggregated regionally to those RIRs, or have regionalized allocation windows. Should that model be allowed? Would it be OK with this model to restrict their forward looking demand or allocation window that can be received from a particular RIR, base on the resources used within the region, but received from which ever RIR? Basically, don't restrict how they are actually use, but restrict the scope of past use can be used to justify the additional of resources to your allocation window from an individual RIR. Said another way; You can have a single global allocation window from one RIR (or only one RIR at a time at least). Otherwise, you can have multiple allocation windows, one from each RIR. In such a case, each allocation window is only based on future needs within each RIR's region and justified only by previous usage within the region. If, you use previous resources outside the region they don't count toward justifying your future in region need in this model. That doesn't say you can't use them out of region but if you do, the out of region use detracts from the size of your next allocation window. Could something like that work conceptually? Or, are you saying that we shouldn't allow regionalized allocation windows at all? Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From alh-ietf at tndh.net Tue Jul 17 17:52:59 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 17 Jul 2012 14:52:59 -0700 Subject: [arin-ppml] ARIN-prop-178 Regional Use of Resources In-Reply-To: <5005D4DA.3040202@umn.edu> References: <500071AE.70105@arin.net> <03a201cd61e3$1ae220b0$50a66210$@tndh.net> <03b101cd6210$92e78e60$b8b6ab20$@tndh.net> <5002FE93.4000503@umn.edu> <04a101cd6382$6b84dc60$428e9520$@tndh.net> <5004B9E3.9080305@umn.edu> <057001cd6435$1f816370$5e842a50$@tndh.net> <5005D4DA.3040202@umn.edu> Message-ID: <059e01cd6466$8982e0b0$9c88a210$@tndh.net> David Farmer wrote: > >> ... > >> Is that what you are saying? > > > > Yes. The point is that everyone has to meet current ARIN policies when > > making a new request. > > > > Where past resources were acquired, or where they are deployed > > globally are irrelevant, as long as the requestor is doing 'proper > > stewardship'; where 'proper' is defined by current criterion > > established at the RIR they are asking to provide more. To me, this is > > the only way to avoid policy conflicts, and deal with pre-RIR > > resources fairly. If the RIR system had not been created, this is > > exactly what they would have to do at IANA, so why should the RIR > mechanism be any different? > > OK, I think I get what your saying now, thanks for your patience in helping me > work through it. > > I believe, that essentially says you can only have your global future demand > or allocation window from one RIR at a time and you can't get anything from > another RIR until you have used up you current allocation window to the > extent required by the next RIR you decide to get > resources from. That works for fine for IPv6 with the single global > aggregate model that X.2 is going after. > > However, there are others that wish to get IPv6 resources and receive an > allocation window from each RIR to aggregated regionally to those RIRs, or > have regionalized allocation windows. Should that model be allowed? > Would it be OK with this model to restrict their forward looking demand or > allocation window that can be received from a particular RIR, base on the > resources used within the region, but received from which ever RIR? > Basically, don't restrict how they are actually use, but restrict the scope of > past use can be used to justify the additional of resources to your allocation > window from an individual RIR. > > Said another way; You can have a single global allocation window from one > RIR (or only one RIR at a time at least). Otherwise, you can have multiple > allocation windows, one from each RIR. In such a case, each allocation > window is only based on future needs within each RIR's region and justified > only by previous usage within the region. If, you use previous resources > outside the region they don't count toward justifying your future in region > need in this model. That doesn't say you can't use them out of region but if > you do, the out of region use detracts from the size of your next allocation > window. > > Could something like that work conceptually? Or, are you saying that we > shouldn't allow regionalized allocation windows at all? I don't see how it works in practice, because there is no way to police it. I understand the desire to have regionalized resources, and how that can make many deployments simpler. What I don't see is how an RIR is in a position to police where a resource gets deployed. The justification documents can show in-region use, but the separation between assignment and operations allows the recipient to move the resources anywhere at any time. If you can figure out some language that allows staff to make consistent judgments about regionalized deployments, I can live with that, but I am skeptical. If someone came in with deployments A,B,C,D,&E, stating that A has resources from RIR-A meeting policy V, B has resources from RIR-B meeting policy W ... now requesting resources for E from RIR-E meeting policy Z, (and there was a background check process in place to verify that what is claimed is what was used at the other RIRs) that would be easy enough for staff to deal with and create a document trail about why an action was taken. Where it breaks down is that the pace of change is faster than processes can deal with, so in real deployment it is never as clean as the documented justification. I am not suggesting people are intentionally bypassing policy, just that the best intentions are rarely the outcome. Once you get into the messy real-world, it is very difficult to weed out those who are intentionally bypassing policy from those that are simply victims of process delays. Developing a policy that can't be enforced may put a feel-good feather in someone's cap, but it does nothing but create an impossible situation for staff. At the end of the day it would appear to be cleaner to have every RIR evaluate global deployed resources against local policy every time. Once resources are assigned you can't reasonably police where they are used, so don't even pretend to try. Tony > > Thanks > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== From info at arin.net Wed Jul 18 18:27:27 2012 From: info at arin.net (ARIN) Date: Wed, 18 Jul 2012 18:27:27 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements - revised Message-ID: <5007384F.5080502@arin.net> ARIN-prop-173 Revisions to M&A Transfer Requirements The proposal originator revised the proposal. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-173 Revisions to M&A Transfer Requirements Proposal Originator - Marc Lindsey Date - 18 July 2012 Policy type - Modification to existing policy Policy term - Permanent Policy Statement Delete sections 8.1. and 8.2 in their entirety and replace them with the following: 8.1 Principles ARIN will not transfer the registration of number resources from one organization to another unless such transfer complies with this Section 8. ARIN is tasked with making prudent, fair and expeditious decisions when evaluating registration transfer requests. It should be understood that number resources directly assigned or allocated by ARIN are not 'sold' under ARIN administration. Rather, such number resources are assigned by ARIN to an organization for its exclusive use, provided that any terms of the applicable Registration Services Agreement between ARIN and the organization governing the use of such number resources continue to be met by such organization. Number resources administered and assigned by ARIN are done so according to ARIN's published policies. ARIN directly assigns and allocates number resources, based on justified need, to organizations, not to individuals representing those organizations. The transfer policies in this Section 8 create certain exceptions and exclusions for legacy numbers ("grandfather policies"). The grandfather policies are intended to satisfy key policy objectives while promoting greater participation in the ARIN community by organizations holding legacy numbers. The grandfather policies allow organizations holding legacy numbers to retain some of the historic benefits attached to their legacy numbers. The benefits of the grandfather policies are not available for legacy numbers if: (a) they are voluntarily and permanently released by the original registrant or its successor (or assign) to an RIR for re-issue to other organizations; where such releases are supported by reliable evidence retained by ARIN or the applicable RIR of the organization's informed and voluntary consent or agreement to permanently release the numbers; or (b) the original registrant or its successor (or assign) of such number enters into an LRSA or RSA expressly referencing the legacy numbers as governed by the terms and conditions of an LRSA or RSA. 8.2. Mergers and Acquisitions When the transfer of any number resource is requested by the current registrant or its successor or assign (the "new entity"), ARIN will transfer the registration of such number resources to the new entity upon receipt of evidence that the new entity lawfully acquired all of the current registrant's rights, title and interest in and to the number resources, including assets used with such number resources, all as the result of a merger, acquisition, reorganization or name change. ARIN will maintain an up-to-date list of acceptable types of documentation. Transfers under this Section 8.2 shall not require: (i) the new entity to justify its need for the transferred numbers, or (ii) the current registrant or the new entity to enter into an LRSA or RSA (or any other contract with ARIN) or to be a party to an existing LRSA or RSA (or any other contract with ARIN). Add the following new definition to Section 2: A "legacy number" means any number resource that meets the following two conditions: (1) the number resource was issued to an entity (other than a Regional Internet Registry) or individual (either, the "original legacy holder") prior to ARIN's inception on Dec 22, 1997 by or through an organization authorized by the United States to issue such number resources; and (2) the original legacy holder (or its legal successor or assign) of such number resource has not voluntarily and permanently released the number resource to a Regional Internet Registry for subsequent allocation or assignment in accordance with such RIR's number resource policies and membership (or service) agreements. Rationale The current version of 8.2 actually discourages legacy holders from (a) updating the registry database, and (b) paying fees to assist with records management associated with the ARIN databases. Some entities that currently control resources do not attempt to update the ARIN registry records because the current transfer process puts at risk their ability to retain and use their numbers. Under the current process, a legacy holder or its lawful successor must first prove that it is the lawful successor (which is necessary and appropriate). But it then must also justify its need to continue using the numbers it obtained prior to ARIN's existence. Once the successor entity passes the needs hurdle, it is required by ARIN to execute an RSA (not an LRSA) as if the numbers were newly allocated from ARIN's free pool. The RSA (and LRSA) substantially alters the rights conveyed to the successor and subjects its numbers to audit and possible revocation under then-current policy. There is, therefore, very little incentive for an M&A successor entity to update the ARIN registry database records. For non-legacy registrants, the process should also be less burdensome and uncertain. Ensuring the continuity of a company's IP addressing scheme as part of an M&A transaction should be within the control of the entities directly involved. ARIN's discretionary approval of transfers in this context introduces an undesirable and unnecessary contingency. Entities concerned about whether their M&A related registration database record update request will be rejected by ARIN simply do not attempt to fully update the records. Adopting this policy will minimize the barriers for both legacy and non-legacy holders to update the registration databases when changes are required to accurately reflect normal corporate reorganization activities, which will help increase the accuracy of the registration databases, which benefits the community as a whole. Timetable for implementation - Immediate From dogwallah at gmail.com Thu Jul 19 13:20:07 2012 From: dogwallah at gmail.com (McTim) Date: Thu, 19 Jul 2012 13:20:07 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements - revised In-Reply-To: <5007384F.5080502@arin.net> References: <5007384F.5080502@arin.net> Message-ID: Hi, On Wed, Jul 18, 2012 at 6:27 PM, ARIN wrote: > ARIN-prop-173 Revisions to M&A Transfer Requirements > > The proposal originator revised the proposal. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-173 Revisions to M&A Transfer Requirements > > Proposal Originator - Marc Lindsey > > Date - 18 July 2012 > > Policy type - Modification to existing policy > > Policy term - Permanent > > Policy Statement > > Delete sections 8.1. and 8.2 in their entirety and replace them with the > following: > > 8.1 Principles > > ARIN will not transfer the registration of number resources from one > organization to another unless such transfer complies with this Section 8. > ARIN is tasked with making prudent, fair and expeditious decisions when > evaluating registration transfer requests. > > It should be understood that number resources directly assigned or allocated > by ARIN are not 'sold' under ARIN administration. The above is correct. The intent of this policy revision seems to me to be to allow entities that are not ARIN to sell Internet resources. Have I got the wrong end of the stick? I ack that I am not the sharpest knife in the drawer, but I can read and comprehend English. Rather, such number > resources are assigned by ARIN to an organization for its exclusive use, > provided that any terms of the applicable Registration Services Agreement > between ARIN and the organization governing the use of such number resources > continue to be met by such organization. Number resources administered and > assigned by ARIN are done so according to ARIN's published policies. > > ARIN directly assigns and allocates number resources, based on justified > need, to organizations, not to individuals representing those organizations. > > The transfer policies in this Section 8 create certain exceptions and > exclusions for legacy numbers ("grandfather policies"). The grandfather > policies are intended to satisfy key These seem to be "key" for only a subset of the community. policy objectives while promoting > greater participation in the ARIN community by organizations holding legacy > numbers. The grandfather policies allow organizations holding legacy > numbers to retain some of the historic benefits attached to their legacy > numbers. > > The benefits of the grandfather policies are not available for legacy > numbers if: > > (a) they are voluntarily and permanently released by the original registrant > or its successor (or assign) to an RIR for re-issue to other organizations; > where such releases are supported by reliable evidence retained by ARIN or > the applicable RIR of the organization's informed and voluntary consent or > agreement to permanently release the numbers; or > > (b) the original registrant or its successor (or assign) of such number > enters into an LRSA or RSA expressly referencing the legacy numbers as > governed by the terms and conditions of an LRSA or RSA. Isn't the effect of the above to be exactly what you say you are trying to avoid? In other words, does this not demotivate holders of early assignments to sign an RSA/LRSA? > > 8.2. Mergers and Acquisitions > > When the transfer of any number resource is requested by the current > registrant or its successor or assign (the "new entity"), ARIN will transfer > the registration of such number resources to the new entity upon receipt of > evidence that the new entity lawfully acquired all of the current > registrant's rights, title and interest in and to the number resources, > including assets used with such number resources, all as the result of a > merger, acquisition, reorganization or name change. ARIN will maintain an > up-to-date list of acceptable types of documentation. Transfers under this > Section 8.2 shall not require: (i) the new entity to justify its need for > the transferred numbers, or So if I have the cash I can buy as many blocks as I want with no regard to how they might actually be used in networks? Am opposed to this notion, it seems to be a huge loophole for speculators. (ii) the current registrant or the new entity to > enter into an LRSA or RSA (or any other contract with ARIN) or to be a party > to an existing LRSA or RSA (or any other contract with ARIN). > > Add the following new definition to Section 2: > > A "legacy number" means any number resource that meets the following two > conditions: > > (1) the number resource was issued to an entity (other than a Regional > Internet Registry) or individual (either, the "original legacy holder") > prior to ARIN's inception on Dec 22, 1997 by or through an organization > authorized by the United States to issue such number resources; and > > (2) the original legacy holder (or its legal successor or assign) of such > number resource has not voluntarily and permanently released the number > resource to a Regional Internet Registry for subsequent allocation or > assignment in accordance with such RIR's number resource policies and > membership (or service) agreements. > > Rationale > > The current version of 8.2 actually discourages legacy holders from (a) > updating the registry database, and (b) paying fees to assist with records > management associated with the ARIN databases. Some entities that currently > control resources do not attempt to update the ARIN registry records because > the current transfer process puts at risk their ability to retain and use > their numbers. What the current process puts "at risk" is their ability to monetize resources at will. > > Under the current process, a legacy holder or its lawful successor must > first prove that it is the lawful successor (which is necessary and > appropriate). But it then must also justify its need to continue using the > numbers it obtained prior to ARIN's existence. yes, this is stewardship. Once the successor entity > passes the needs hurdle, more like a curb than a hurdle. The bar isn't as high as some rhetoric suggests. it is required by ARIN to execute an RSA (not an > LRSA) as if the numbers were newly allocated from ARIN's free pool. The > RSA (and LRSA) substantially alters the rights conveyed to the successor and > subjects its numbers to audit and possible revocation under then-current > policy. There is, therefore, very little incentive for an M&A successor > entity to update the ARIN registry database records. routing considerations should be incentive enough. > > For non-legacy registrants, the process should also be less burdensome and > uncertain. Ensuring the continuity of a company's IP addressing scheme as > part of an M&A transaction should be within the control of the entities > directly involved. ARIN's discretionary approval of transfers in this > context introduces an undesirable and unnecessary contingency. > > Entities concerned about whether their M&A related registration database > record update request will be rejected by ARIN simply do not attempt to > fully update the records. but you haven't introduced policy text for this. do you intend to do that? Does this policy cover non-legacy registrations? If so I will have to read it a 3rd time ;-/ > > Adopting this policy will minimize the barriers for both legacy and > non-legacy holders to update the registration databases when changes are > required to accurately reflect normal corporate reorganization activities, > which will help increase the accuracy of the registration databases, which > benefits the community as a whole. It also seems to fully monetize legacy resources...or have i missed something? -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From jmaimon at chl.com Thu Jul 19 15:26:48 2012 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 19 Jul 2012 15:26:48 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 Message-ID: <50085F78.7010802@chl.com> All, Policy Proposal #168 Promote 4byte ASN Usage, was intended to deal with the lack of uptake of 4byte ASN as well as the continued demand for 2byte ASN. It does so by expanding on the capabilities of both the community and ARIN with regards to ASN policy. I believe that more discussion on this topic is warranted. ARIN Staff said as much at previous PPM and I was hoping that this proposal would help do that. As such, the AC's abandonment of this proposal was disappointing to me. While it may not be as compelling and controversial as some of the topics swirling through the list these days, ASN policy is important, disproportionately so, to the newcomers of our community. I formally petition you, the members of this community, for your support in advancing to draft policy status the proposal and for it to be discussed at an upcoming ARIN Public Policy meeting. I ask you for statements in support of this petition. The full policy proposal text is available at http://lists.arin.net/pipermail/arin-ppml/2012-May/024892.html Best and my thanks, Joe From lar at mwtcorp.net Thu Jul 19 15:27:36 2012 From: lar at mwtcorp.net (Larry Ash) Date: Thu, 19 Jul 2012 13:27:36 -0600 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements - revised In-Reply-To: References: <5007384F.5080502@arin.net> Message-ID: On Thu, 19 Jul 2012 13:20:07 -0400 McTim wrote: > Hi, > > On Wed, Jul 18, 2012 at 6:27 PM, ARIN wrote: >> ARIN-prop-173 Revisions to M&A Transfer Requirements >> >> The proposal originator revised the proposal. >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> ARIN-prop-173 Revisions to M&A Transfer Requirements >> >> Proposal Originator - Marc Lindsey >> >> Date - 18 July 2012 >> >> Policy type - Modification to existing policy >> >> Policy term - Permanent >> >> Policy Statement >> >> Delete sections 8.1. and 8.2 in their entirety and replace them with the >> following: >> >> 8.1 Principles >> >> ARIN will not transfer the registration of number resources from one >> organization to another unless such transfer complies with this Section 8. >> ARIN is tasked with making prudent, fair and expeditious decisions when >> evaluating registration transfer requests. >> >> It should be understood that number resources directly assigned or allocated >> by ARIN are not 'sold' under ARIN administration. > > > The above is correct. The intent of this policy revision seems to me to be >to > allow entities that are not ARIN to sell Internet resources. > > Have I got the wrong end of the stick? > > I ack that I am not the sharpest knife in the drawer, but I can read > and comprehend English. > It seams to me that we will be continually besieged with these proposals until we formulate and adopt a policy that in short says: If you received your direct allocation after Dec 22, 1997 no matter what the method or circumstances, are located within the ARIN footprint, and did not, or have not, a) signed a RSA or LRSA and b) justified the need for those addresses; then the addresses are subject to revocation and reassignment. Period I trust that this would have to be adjudicated but I also trust that ARIN's legal staff are astute enough to choose the case with the greatest chance of success and that they would prevail. In at least the case of IPV4, there is clearly an argument that some type of governance for number assignment is required and just refusing to submit to that governance because: I don't feel I should have to, doesn't seem like a winning argument. (Obviously IMNAL.) Needless to say I don't support the proposal and am tired of the argument associated with it. I mean no disrespect to Mr. Lindsey but I thought that the list made it's wishes clear before. > > > Rather, such number >> resources are assigned by ARIN to an organization for its exclusive use, >> provided that any terms of the applicable Registration Services Agreement >> between ARIN and the organization governing the use of such number resources >> continue to be met by such organization. Number resources administered and >> assigned by ARIN are done so according to ARIN's published policies. >> >> ARIN directly assigns and allocates number resources, based on justified >> need, to organizations, not to individuals representing those organizations. >> >> The transfer policies in this Section 8 create certain exceptions and >> exclusions for legacy numbers ("grandfather policies"). The grandfather >> policies are intended to satisfy key > > These seem to be "key" for only a subset of the community. > > > policy objectives while promoting >> greater participation in the ARIN community by organizations holding legacy >> numbers. The grandfather policies allow organizations holding legacy >> numbers to retain some of the historic benefits attached to their legacy >> numbers. >> >> The benefits of the grandfather policies are not available for legacy >> numbers if: >> >> (a) they are voluntarily and permanently released by the original registrant >> or its successor (or assign) to an RIR for re-issue to other organizations; >> where such releases are supported by reliable evidence retained by ARIN or >> the applicable RIR of the organization's informed and voluntary consent or >> agreement to permanently release the numbers; or >> >> (b) the original registrant or its successor (or assign) of such number >> enters into an LRSA or RSA expressly referencing the legacy numbers as >> governed by the terms and conditions of an LRSA or RSA. > > Isn't the effect of the above to be exactly what you say you are > trying to avoid? > > In other words, does this not demotivate holders of early assignments > to sign an RSA/LRSA? > > >> >> 8.2. Mergers and Acquisitions >> >> When the transfer of any number resource is requested by the current >> registrant or its successor or assign (the "new entity"), ARIN will transfer >> the registration of such number resources to the new entity upon receipt of >> evidence that the new entity lawfully acquired all of the current >> registrant's rights, title and interest in and to the number resources, >> including assets used with such number resources, all as the result of a >> merger, acquisition, reorganization or name change. ARIN will maintain an >> up-to-date list of acceptable types of documentation. Transfers under this >> Section 8.2 shall not require: (i) the new entity to justify its need for >> the transferred numbers, or > > > So if I have the cash I can buy as many blocks as I want with no regard to > how they might actually be used in networks? > > Am opposed to this notion, it seems to be a huge loophole for speculators. > > > (ii) the current registrant or the new entity to >> enter into an LRSA or RSA (or any other contract with ARIN) or to be a party >> to an existing LRSA or RSA (or any other contract with ARIN). >> >> Add the following new definition to Section 2: >> >> A "legacy number" means any number resource that meets the following two >> conditions: >> >> (1) the number resource was issued to an entity (other than a Regional >> Internet Registry) or individual (either, the "original legacy holder") >> prior to ARIN's inception on Dec 22, 1997 by or through an organization >> authorized by the United States to issue such number resources; and >> >> (2) the original legacy holder (or its legal successor or assign) of such >> number resource has not voluntarily and permanently released the number >> resource to a Regional Internet Registry for subsequent allocation or >> assignment in accordance with such RIR's number resource policies and >> membership (or service) agreements. >> >> Rationale >> >> The current version of 8.2 actually discourages legacy holders from (a) >> updating the registry database, and (b) paying fees to assist with records >> management associated with the ARIN databases. Some entities that currently >> control resources do not attempt to update the ARIN registry records because >> the current transfer process puts at risk their ability to retain and use >> their numbers. > > What the current process puts "at risk" is their ability to monetize > resources at will. > > >> >> Under the current process, a legacy holder or its lawful successor must >> first prove that it is the lawful successor (which is necessary and >> appropriate). But it then must also justify its need to continue using the >> numbers it obtained prior to ARIN's existence. > > yes, this is stewardship. > > > Once the successor entity >> passes the needs hurdle, > > more like a curb than a hurdle. The bar isn't as high as some > rhetoric suggests. > > it is required by ARIN to execute an RSA (not an >> LRSA) as if the numbers were newly allocated from ARIN's free pool. The >> RSA (and LRSA) substantially alters the rights conveyed to the successor and >> subjects its numbers to audit and possible revocation under then-current >> policy. There is, therefore, very little incentive for an M&A successor >> entity to update the ARIN registry database records. > > routing considerations should be incentive enough. > >> >> For non-legacy registrants, the process should also be less burdensome and >> uncertain. Ensuring the continuity of a company's IP addressing scheme as >> part of an M&A transaction should be within the control of the entities >> directly involved. ARIN's discretionary approval of transfers in this >> context introduces an undesirable and unnecessary contingency. >> >> Entities concerned about whether their M&A related registration database >> record update request will be rejected by ARIN simply do not attempt to >> fully update the records. > > but you haven't introduced policy text for this. do you intend to do that? > > Does this policy cover non-legacy registrations? If so I will have to > read it a 3rd time ;-/ > >> >> Adopting this policy will minimize the barriers for both legacy and >> non-legacy holders to update the registration databases when changes are >> required to accurately reflect normal corporate reorganization activities, >> which will help increase the accuracy of the registration databases, which >> benefits the community as a whole. > > It also seems to fully monetize legacy resources...or have i missed >something? > > -- > Cheers, > > McTim > "A name indicates what we seek. An address indicates where it is. A > route indicates how we get there." Jon Postel > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From hannigan at gmail.com Thu Jul 19 15:48:32 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 19 Jul 2012 15:48:32 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements - revised In-Reply-To: References: <5007384F.5080502@arin.net> Message-ID: The list is comprised of more than five people. I'd sincerely appreciate it if you'd speak for yourself. Best, Marty On Thursday, July 19, 2012, Larry Ash wrote: > On Thu, 19 Jul 2012 13:20:07 -0400 > McTim wrote: > >> Hi, >> >> On Wed, Jul 18, 2012 at 6:27 PM, ARIN wrote: >> >>> ARIN-prop-173 Revisions to M&A Transfer Requirements >>> >>> The proposal originator revised the proposal. >>> >>> Regards, >>> >>> Communications and Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> >>> ARIN-prop-173 Revisions to M&A Transfer Requirements >>> >>> Proposal Originator - Marc Lindsey >>> >>> Date - 18 July 2012 >>> >>> Policy type - Modification to existing policy >>> >>> Policy term - Permanent >>> >>> Policy Statement >>> >>> Delete sections 8.1. and 8.2 in their entirety and replace them with the >>> following: >>> >>> 8.1 Principles >>> >>> ARIN will not transfer the registration of number resources from one >>> organization to another unless such transfer complies with this Section >>> 8. >>> ARIN is tasked with making prudent, fair and expeditious decisions when >>> evaluating registration transfer requests. >>> >>> It should be understood that number resources directly assigned or >>> allocated >>> by ARIN are not 'sold' under ARIN administration. >>> >> >> >> The above is correct. The intent of this policy revision seems to me to >> be to >> allow entities that are not ARIN to sell Internet resources. >> >> Have I got the wrong end of the stick? >> >> I ack that I am not the sharpest knife in the drawer, but I can read >> and comprehend English. >> >> > > > It seams to me that we will be continually besieged with these proposals > until > we formulate and adopt a policy that in short says: > > If you received your direct allocation after Dec 22, 1997 no matter what > the method > or circumstances, are located within the ARIN footprint, and did not, or > have not, > a) signed a RSA or LRSA and b) justified the need for those addresses; > then the addresses are subject to revocation and reassignment. Period > > I trust that this would have to be adjudicated but I also trust that > ARIN's legal > staff are astute enough to choose the case with the greatest chance of > success and > that they would prevail. In at least the case of IPV4, there is clearly an > argument > that some type of governance for number assignment is required and just > refusing to > submit to that governance because: I don't feel I should have to, doesn't > seem like a > winning argument. (Obviously IMNAL.) > > Needless to say I don't support the proposal and am tired of the argument > associated > with it. I mean no disrespect to Mr. Lindsey but I thought that the list > made it's > wishes clear before. > > > > > > > Rather, such number > > resources are assigned by ARIN to an organization for its exclusive use, > provided that any terms of the applicable Registration Services Agreement > between ARIN and the organization governing the use of such number > resources > continue to be met by such organization. Number resources administered and > assigned by ARIN are done so according to ARIN's published policies. > > ARIN directly assigns and allocates number resources, based on justified > need, to organizations, not to individuals representing those > organizations. > > The transfer policies in this Section 8 create certain exceptions and > exclusions for legacy numbers ("grandfather policies"). The grandfather > policies are intended to satisfy key > > > These seem to be "key" for only a subset of the community. > > > policy objectives while promoting > > greater participation in the ARIN community by organizations holding legacy > numbers. The grandfather policies allow organizations holding legacy > numbers to retain some of the historic benefits attached to their legacy > numbers. > > The benefits of the grandfather policies are not available for legacy > numbers if: > > (a) they are voluntarily and permanently released by the original > registrant > or its successor (or assign) to an RIR for re-issue to other organizations; > where such releases are supported by reliable evidence retained by ARIN or > the applicable RIR of the organization's informed and voluntary consent or > agreement to permanently release the numbers; or > > (b) the original registrant or its successor (or assign) of such number > enters into an LRSA or RSA expressly referencing the legacy numbers as > governed by the terms and conditions of an LRSA or RSA. > > > Isn't the effect of the above to be exactly what you say you are > trying to avoid? > > In other words, does this not demotivate holders of early assignments > to sign an RSA/LRSA? > > > > 8.2. Mergers and Acquisitions > > When the transfer of any number resource is requested by the current > registrant or its successor or assign (the "new entity"), ARIN will > transfer > the registration of such number resources to the new entity upon receipt of > evidence that the new entity lawfully acquired all of the current > registrant's rights, title and interest in and to the number resources, > including assets used with such number resources, all as the result of a > merger, acquisition, reorganization or name change. ARIN will maintain an > up-to-date list of acceptable types of documentation. Transfers under this > Section 8.2 shall not require: (i) the new entity to justify its need for > the transferred numbers, or > > > > So if I have the cash I can buy as many blocks as I want with no regard to > how they might actually be used in networks? > > Am opposed to this notion, it seems to be a huge loophole for speculators. > > > (ii) the current registrant or the new entity to > > enter into an LRSA or RSA (or any other contract with ARIN) or to be a > party > to an existing LRSA or RSA (or any other contract with ARIN). > > Add the following new definition to Section 2: > > A "legacy number" means any number resource that meets the following two > conditions: > > (1) the number resource was issued to an entity (other than a Regional > Internet Registry) or individual (either, the "original legacy holder") > prior to ARIN's inception on Dec 22, 1997 by or through an organization > authorized by the United States to issue such number resources; and > > (2) the original legacy holder (or its legal successor or assign) of such > number resource has not voluntarily and permanently released the number > resource to a Regional Internet Registry for subsequent allocation or > assignment in accordance with such RIR's number resource policies and > membership (or service) agreements. > > Rationale > > The current version of 8.2 actually discourages legacy holders from (a) > updating the registry database, and (b) paying fees to assist with records > management associated with the ARIN databases. Some entities that > currently > control resources do not attempt to update the ARIN registry records > because > the current transfer process puts at risk their ability to retain and use > > Larry Ash > Network Administrator > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 > ______________________________**_________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/**listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Sent via a mobile device -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.herbert at gmail.com Thu Jul 19 16:42:29 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 19 Jul 2012 13:42:29 -0700 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Requirements - revised In-Reply-To: References: <5007384F.5080502@arin.net> Message-ID: On Thu, Jul 19, 2012 at 12:27 PM, Larry Ash wrote: > > It seams to me that we will be continually besieged with these proposals > until > we formulate and adopt a policy that in short says: > > If you received your direct allocation after Dec 22, 1997 no matter what the > method > or circumstances, are located within the ARIN footprint, and did not, or > have not, > a) signed a RSA or LRSA and b) justified the need for those addresses; > then the addresses are subject to revocation and reassignment. Period > > I trust that this would have to be adjudicated but I also trust that ARIN's > legal > staff are astute enough to choose the case with the greatest chance of > success and > that they would prevail. In at least the case of IPV4, there is clearly an > argument > that some type of governance for number assignment is required and just > refusing to > submit to that governance because: I don't feel I should have to, doesn't > seem like a > winning argument. (Obviously IMNAL.) > > Needless to say I don't support the proposal and am tired of the argument > associated > with it. I mean no disrespect to Mr. Lindsey but I thought that the list > made it's > wishes clear before. I am relatively new to ppml, (only about a year or two), but... It does not sem to me that you are accurately reflecting either the discussions I have seen on list (or at least, the major consensus-groups I have seen on list, as there is no unified consensus), nor the wider community consensus groups. The absolutist "or else" position seems by a large majority to be felt to either be outright wrong, or sufficiently risky that it's highly unwise. It seems to me that encouraging legacy number assignees to keep their paperwork status up to date is a good thing, and ultimately neutral in other policy discussions. It does not finally resolve the "what do we do with legacy numbers" problem, but at least helps administrative and operational recordkeeping. Having records indicating a now-defunct assignee where a successor legitimately exists and is known doesn't help anyone. People use these records operationally, all the time, trying to get in touch with each other over issues. Certainly there are legitimate policy issues, but one of the policy issues is that the bits have to keep flowing, and the people who have to keep bits flowing needs to have data about other people and endpoints. -- -george william herbert george.herbert at gmail.com From info at arin.net Thu Jul 19 17:51:04 2012 From: info at arin.net (ARIN) Date: Thu, 19 Jul 2012 17:51:04 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 Message-ID: <50088148.1040003@arin.net> ARIN-prop-168 Promote 4byte ASN Usage The message below started a petition regarding the ARIN Advisory Council's decision to abandon ARIN-prop-168. The AC's decision was posted by ARIN staff to PPML on 26 June 2012. If successful, this petition will change ARIN-prop-168 into a Draft Policy which will be published for adoption discussion on the PPML and at the Public Policy Meeting in October 2012. If the petition fails, the proposal will be closed. For this petition to be successful, the petition needs statements of support from at least 10 different people from 10 different organizations. If you wish to support this petition, post a statement of support to PPML on this thread. The duration of the petition is five business days; it ends on 26 July 2012. ARIN staff will post the result of the petition to PPML. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The proposal text is below and at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ##### > -----Original Message----- > From: Joe Maimon > Date: Thu, 19 Jul 2012 15:26:48 -0400 > To: "ppml >> \"ppml at arin.net\"" > Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 > > All, > > Policy Proposal #168 Promote 4byte ASN Usage, was intended to deal with > the lack of uptake of 4byte ASN as well as the continued demand for > 2byte ASN. > > It does so by expanding on the capabilities of both the community and > ARIN with regards to ASN policy. > > I believe that more discussion on this topic is warranted. ARIN Staff > said as much at previous PPM and I was hoping that this proposal would > help do that. > > As such, the AC's abandonment of this proposal was disappointing to me. > > While it may not be as compelling and controversial as some of the > topics swirling through the list these days, ASN policy is important, > disproportionately so, to the newcomers of our community. > > I formally petition you, the members of this community, for your support > in advancing to draft policy status the proposal and for it to be > discussed at an upcoming ARIN Public Policy meeting. > > I ask you for statements in support of this petition. > > The full policy proposal text is available at > > http://lists.arin.net/pipermail/arin-ppml/2012-May/024892.html > > Best and my thanks, > > Joe > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. ARIN-prop-168 Promote 4byte ASN Usage Proposal Originator: Joe Maimon Proposal Version: 1.1 Date: 18 May 2012 Proposal type: Modify Policy term: Temporary Policy statement: Add section 5.2 5.2 Guidelines ARIN will issue AS Numbers under the following guidelines. 5.2.1 Unused ARIN will attempt to assign to the organization an AS Number which has neither been previously assigned nor publicly used, as available. 5.2.2 Requests An organization may request from ARIN either a specific AS Number or type of AS Number, if available to ARIN. The organization must document to ARIN's satisfaction technical or real world justification for its request. ARIN may review the data directly with all involved parties. 5.2.3 Rectification ARIN may reuse the provided documentation in such public and private forums as it deems appropriate and useful to promote the rectification of issues documented via 5.2.2 request justification. 5.2.4 Restrictions Assignments received via 5.2.2 requests are additionally restricted from 8.3 transfers for a period of 24 months post assignment. 5.2.5 Release An organization can exchange the 5.2.2 number for a 5.2.1 number, after which time the restriction on transferring the assignment will be released. 5.2.6 Publication Section 5.2 neither requires nor recommends that ARIN publicize its available AS Numbers. 5.2.7 Expiration ARIN may retire section 5.2 anytime during a period of more than 24 calendar months that have gone by without any completed 5.2.2 requests. Rationale: Changes from V1.0 5.2.1 "used" -> "publicly used" 5.2.2 "must provide" -> "must document" 5.2.2 "technical justification " -> "technical or real world justification" 5.2.3 strike "with suitable privacy considerations in place" 5.2.3 "public forums" -> "public or private forums" 5.2.3 "necessary to promote" -> "appropriate and useful to promote" 5.2.3 "rectification of documented causes" -> "rectification of issues documented via 5.2.2 request justification" 5.2.4 "being transferred" -> "from 8.3 transfers" 5.2.7 "after a period of" -> "during a period of more than" Unless otherwise requested, providing an ASN with no baggage or history should be preferential to both the organization and to ARIN. The restrictions and clauses regarding technical justification are designed for the promotion of 4byte ASN uptake and preservation of 2byte ASN's for those who truly need them. Additionally, this may help to assist in resolving apparently pervasive obstacles in the ARIN region to using 4byte ASN's. Further, if an organization does have a valid technical justification for a specific AS Number that is available, for example, when a network was built with an ASN that was subsequently reclaimed due to accidental negligence or other similar cases, there is little benefit to ARIN refusing to provide the organization what it can show it needs. ARIN need not publicize available ASNs but it may choose to do so if it is the most efficient and prudent method of implementation. Should this policy become a relic (we hope), ARIN is expressly authorized to excise it. Timetable for implementation: Immediate. From mlindsey at lb3law.com Thu Jul 19 18:51:10 2012 From: mlindsey at lb3law.com (Lindsey, Marc) Date: Thu, 19 Jul 2012 18:51:10 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Message-ID: <98E8C412B2F47D48A79816422B860E1B04B9EC926F7D@lb3ex01> Dear McTim, Thank you for taking the time to review and comment on my revised proposal. I reviewed all of the previous comments on the PPML and from the staff, and I made several revisions to the prior text in response to those comments. Below are my responses to some of your specific comments to this latest version. > 8.1 Principles > > ARIN will not transfer the registration of number resources from one > organization to another unless such transfer complies with this Section 8. > ARIN is tasked with making prudent, fair and expeditious decisions > when evaluating registration transfer requests. > > It should be understood that number resources directly assigned or > allocated by ARIN are not 'sold' under ARIN administration. You wrote: The above is correct. The intent of this policy revision seems to me to be to allow entities that are not ARIN to sell Internet resources. <<< M Lindsey Reply>>> Current policy allows entities not subject to ARIN's administration to sell legacy resources so I'm not sure why you would object to the proposal based on this. Under current policy, holders of legacy space not subject to an LRSA can, if they find a willing buyer, convey their numbers in exchange for money without submitting to ARIN's administration. Under current policy, the buyers/recipients of those legacy numbers who want ARIN to update its registry database submit to ARIN's administration/records update requirements under 8.3. This proposed policy does not change the way registration transfers between two parties occur under 8.3. > The transfer policies in this Section 8 create certain exceptions and > exclusions for legacy numbers ("grandfather policies"). The > grandfather policies are intended to satisfy key You wrote: These seem to be "key" for only a subset of the community. <<< M Lindsey Reply>>> Entities that hold legacy resources are stakeholders in number policy whether or not they are ARIN members. I would counter that those opposed to policies that either (a) liberalize the transfer policies or (b) recognize the distinction between legacy and non-legacy numbers are also a "subset" of the community. Which subset is larger is an interesting discussion to have over drinks, but I don't think that question has to be answered to adopt policies that fairly balance the subsets' interests (though neither may get all that they want but then that's the nature of constructive compromises). You wrote: Isn't the effect of the above to be exactly what you say you are trying to avoid? In other words, does this not demotivate holders of early assignments to sign an RSA/LRSA? <<< M Lindsey Reply>>> Generally, legacy holders that have not signed the LRSA to date are, as class (I'm generalizing), not motivated to sign. Forcing them to sign what they otherwise believe is not a good deal in order to update the registration records for the benefit of the entire community in my view has de-motivated such legacy holders from contributing updates to ARIN's database. And the more inaccurate the database becomes the less useful it will be as a reference tool for routing decisions. If, on the other hand, you believe that the LRSA/RSA is a good deal on its own merits, then forcing legacy numbers through an LRSA/RSA to update the records to document successors of M&A transactions should be unnecessary. By the way, the LRSA isn't (ordinarily) made available to recipients of M&A transfers of legacy numbers. > 8.2. Mergers and Acquisitions > > When the transfer of any number resource is requested by the current > registrant or its successor or assign (the "new entity"), ARIN will > transfer the registration of such number resources to the new entity > upon receipt of evidence that the new entity lawfully acquired all of > the current registrant's rights, title and interest in and to the > number resources, including assets used with such number resources, > all as the result of a merger, acquisition, reorganization or name > change. ARIN will maintain an up-to-date list of acceptable types of > documentation. Transfers under this Section 8.2 shall not require: (i) > the new entity to justify its need for the transferred numbers, or Your wrote: So if I have the cash I can buy as many blocks as I want with no regard to how they might actually be used in networks? <<< M Lindsey Reply>>> I believe you are referring to the elimination of needs assessment. Your objection, in my view, is too heavily focused on protecting the community from speculators at the expense of providing members and non-members appropriate flexibility to engage in legitimate M&A transactions. In a commercial industry (e.g., operating networks for profit) where the cost of acquiring an important revenue generating input (IP addresses) is affected by time, supply and demand, there will always be smart people that will take advantage of the pricing curve and information asymmetry. This isn't speculation, it's smart business. If ARIN goes too far to build up a policy perimeter anticipating a horde speculating number flippers are just over the horizon, I believe that ARIN members (and possibly -but less so -the broader Internet community) will be harmed by a self-imposed siege. > Rationale > > The current version of 8.2 actually discourages legacy holders from > (a) updating the registry database, and (b) paying fees to assist with > records management associated with the ARIN databases. Some entities > that currently control resources do not attempt to update the ARIN > registry records because the current transfer process puts at risk > their ability to retain and use their numbers. You wrote: What the current process puts "at risk" is their ability to monetize resources at will. <<< M Lindsey Reply>>> I'm not sure I understand the basis of this objection. I don't believe you object to IP numbers generating revenue for those that hold them. Most/many network operators that are members of ARIN "monetize" number resources "at will" by packaging/renting them with other services they provide to customers for a fee. Is the objection based on the assumption that ONLY network operators should be allowed to monetize IP numbers? But again, this policy proposal is about M&A transactions not transfers of numbers (on a standalone basis) between entities as covered by 8.3. And current policy already allows number holders to monetize those numbers, including via registration transfers to designated recipients. > Under the current process, a legacy holder or its lawful successor > must first prove that it is the lawful successor (which is necessary > and appropriate). But it then must also justify its need to continue > using the numbers it obtained prior to ARIN's existence. You wrote: yes, this is stewardship. <<< M Lindsey Reply>>> This sort of stewardship is adversely affecting ARIN's ability to maintain accurate registration databases. Shouldn't database accuracy be an important element of ARIN's stewardship? I also think, as a practical matter, the stewardship approach applied to unallocated resources ought to be different than the stewardship approach applied to non-legacy allocated resources. It has to be (either by design or effect) different for legacy (allocated) numbers. > Once the successor entity > passes the needs hurdle, Your wrote: more like a curb than a hurdle. The bar isn't as high as some rhetoric suggests. <<< M Lindsey Reply>>> We can agree to disagree on the size of the curb or hurdle. I will, however, concede that it may merely be a worn-down speed bump for network operators who know how to optimize the policies. For others, it's more onerous. Regardless, can we at least agree in the context of M&A transactions to remove ARIN's curb/speed bump/hurdle from the middle of corporate reorganization / business continuity decisions? > it is required by ARIN to execute an RSA (not an > LRSA) as if the numbers were newly allocated from ARIN's free pool. The > RSA (and LRSA) substantially alters the rights conveyed to the > successor and subjects its numbers to audit and possible revocation > under then-current policy. There is, therefore, very little incentive > for an M&A successor entity to update the ARIN registry database records. You wrote: routing considerations should be incentive enough. <<< M Lindsey Reply>>> Are you suggesting that only those number resources with accurate ARIN WHOIS registration entries are routed? You wrote: Does this policy cover non-legacy registrations? If so I will have to read it a 3rd time ;-/ <<< M Lindsey Reply>>> The policy removes needs assessment for both legacy and non-legacy numbers conveyed as part of M&A transactions. > Adopting this policy will minimize the barriers for both legacy and > non-legacy holders to update the registration databases when changes > are required to accurately reflect normal corporate reorganization > activities, which will help increase the accuracy of the registration > databases, which benefits the community as a whole. You wrote: It also seems to fully monetize legacy resources...or have i missed something? <<< M Lindsey Reply>>> Yes, I believe you have missed a key point of the proposal. Legacy resources are being "monetized" under existing policies. Hopefully, my responses above clarify the intended effect of my 8.2 policy proposal. * * * Regards, Marc Lindsey Levine, Blaszak, Block & Boothby, LLP 2001 L Street, NW Suite 900 Washington, DC 20036 Phone: (202) 857-2564 Email: mlindsey at lb3law.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlindsey at lb3law.com Thu Jul 19 19:17:12 2012 From: mlindsey at lb3law.com (Lindsey, Marc) Date: Thu, 19 Jul 2012 19:17:12 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer In-Reply-To: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> References: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> Message-ID: <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> Dear Larry, You wrote: It seams to me that we will be continually besieged with these proposals . . . . Needless to say I don't support the proposal and am tired of the argument associated with it. I mean no disrespect to Mr. Lindsey but I thought that the list made it's wishes clear before. <<< M Lindsey Reply>>> As far as I know, the proposal is still under consideration and has not been abandoned by the AC. There have been both supporters and detractors of the prior drafts. I have read and considered comments from the critics, supporters and ARIN staff, and have revised the proposal text several times in an attempt to address many (but certainly not all) of the concerns raised. Notwithstanding your apparent weariness of entertaining viewpoints that differ from your own, in my opinion the PPML is a valuable policy development tool because many on the list (including me) are willing to keep an open mind, revisit their prior assumptions, and consider the merits of contrary arguments. But I have noted your general objection to this policy and others like it, and I'll consider any further responses from you on the topic as a less disrespectful . Marc Lindsey Levine, Blaszak, Block & Boothby, LLP 2001 L Street, NW Suite 900 Washington, DC 20036 Phone: (202) 857-2564 Email: mlindsey at lb3law.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Thu Jul 19 20:50:24 2012 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 20 Jul 2012 00:50:24 +0000 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer In-Reply-To: <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> References: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> Message-ID: <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> Viewing posts to this forum over time, I have concluded that there are a lot of folks who?s opinion is that ARIN should just take control of all legacy resources and manage them however they please with input from this forum. Then there are a lot of folks who?s opinion is that ARIN essentially doesn?t have authority over the Legacy holders resources. Certainly all members of this forum have an equal right to their opinion and an equal right to express them here. I?m not sure which holders of /8?s and other large blocks are still in Legacy status but the list reads like a who?s who of Fortune 500 companies. I don?t ever see comments from those companies stating their opinions in this forum, but you can be sure their attorney?s would have an opinion and would act decisively should ARIN and this forum of Members ever try and reclaim (take) those Legacy resources away from them. As a Legacy holder of one measly /24 block it is my opinion that ARIN and the members of this Forum don?t have the right to just reclaim (take) those resources away from Legacy holders. That is just my opinion and I?m entitled to it - and as a member I can share it in a constructive manner. Based on some off forum email messages I?ve received I think that there are a lot of Members who would completely agree with me. I sense that many have tried in the past to share their view in this forum, and have tired of trying to convince this community to embrace the Legacy community in a reasonable prudent way for all and join with them in ARIN?s mission of furthering Internet usage. Maybe the prudent thing to do is hold a vote and encourage every member to vote ,even Members that rarely if ever post to this Forum. I?m guessing that there would be a lot of Members voting - and seeing a healthy vote total might be the common ground needed to fairly and prudently address the Legacy holders and non-Legacy Holders need to work together for the common mission. I strongly disagree with Larry?s comments but I do share his desire to see this resolved once and for all. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lindsey, Marc Sent: Thursday, July 19, 2012 7:17 PM To: 'arin-ppml at arin.net' Subject: Re: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer Dear Larry, You wrote: It seams to me that we will be continually besieged with these proposals . . . . Needless to say I don't support the proposal and am tired of the argument associated with it. I mean no disrespect to Mr. Lindsey but I thought that the list made it's wishes clear before. <<< M Lindsey Reply>>> As far as I know, the proposal is still under consideration and has not been abandoned by the AC. There have been both supporters and detractors of the prior drafts. I have read and considered comments from the critics, supporters and ARIN staff, and have revised the proposal text several times in an attempt to address many (but certainly not all) of the concerns raised. Notwithstanding your apparent weariness of entertaining viewpoints that differ from your own, in my opinion the PPML is a valuable policy development tool because many on the list (including me) are willing to keep an open mind, revisit their prior assumptions, and consider the merits of contrary arguments. But I have noted your general objection to this policy and others like it, and I?ll consider any further responses from you on the topic as a less disrespectful . Marc Lindsey Levine, Blaszak, Block & Boothby, LLP 2001 L Street, NW Suite 900 Washington, DC 20036 Phone: (202) 857-2564 Email: mlindsey at lb3law.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From jcurran at arin.net Thu Jul 19 21:57:01 2012 From: jcurran at arin.net (John Curran) Date: Fri, 20 Jul 2012 01:57:01 +0000 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer In-Reply-To: <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> References: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> Message-ID: <0793F933-9856-4041-8450-855DD128F3F9@corp.arin.net> On Jul 19, 2012, at 8:50 PM, Steven Ryerse wrote: Viewing posts to this forum over time, I have concluded that there are a lot of folks who?s opinion is that ARIN should just take control of all legacy resources and manage them however they please with input from this forum. Then there are a lot of folks who?s opinion is that ARIN essentially doesn?t have authority over the Legacy holders resources. Certainly all members of this forum have an equal right to their opinion and an equal right to express them here. I?m not sure which holders of /8?s and other large blocks are still in Legacy status but the list reads like a who?s who of Fortune 500 companies. I don?t ever see comments from those companies stating their opinions in this forum, but you can be sure their attorney?s would have an opinion and would act decisively should ARIN and this forum of Members ever try and reclaim (take) those Legacy resources away from them. As a Legacy holder of one measly /24 block it is my opinion that ARIN and the members of this Forum don?t have the right to just reclaim (take) those resources away from Legacy holders. That is just my opinion and I?m entitled to it - and as a member I can share it in a constructive manner. Based on some off forum email messages I?ve received I think that there are a lot of Members who would completely agree with me. I sense that many have tried in the past to share their view in this forum, and have tired of trying to convince this community to embrace the Legacy community in a reasonable prudent way for all and join with them in ARIN?s mission of furthering Internet usage. Steven - I'm not aware of any policy discussions calling for the reclamation of resources from legacy holders. In fact, such policy discussions are unlikely to be very productive, since the legacy registration agreement contractually precludes reclamation from legacy resource holders; see for details. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Thu Jul 19 22:14:10 2012 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 20 Jul 2012 02:14:10 +0000 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer In-Reply-To: <0793F933-9856-4041-8450-855DD128F3F9@corp.arin.net> References: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> <0793F933-9856-4041-8450-855DD128F3F9@corp.arin.net> Message-ID: <5C4532955356D2448E74A170672797E60110E0ECD6@ENI-MAIL.eclipse-networks.com> I appreciate the input! I?ve read thru that section and it is helpful. Unfortunately there appear to be Members who would prefer to have ARIN just reclaim all Legacy resources unilaterally. I understand that a Legacy holder can decide to sign the LSRA, but if they elect not to for whatever reason(s) - hopefully this ?Community? will never decide at some point to change ARINs policies to allow reclaiming Legacy resources unilaterally. This is less likely while ARIN still has IPv4 Addresses & AS numbers to assign, but once they are gone, there is no guarantee that cooler heads will prevail. It would be good if this issue was fully addressed once and for all. The fact that I frequently see opinions both ways in the forum tells me it has not been addressed adequately yet despite the current ARIN policies that have been adopted in the past. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: John Curran [mailto:jcurran at arin.net] Sent: Thursday, July 19, 2012 9:57 PM To: Steven Ryerse Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer On Jul 19, 2012, at 8:50 PM, Steven Ryerse wrote: Viewing posts to this forum over time, I have concluded that there are a lot of folks who?s opinion is that ARIN should just take control of all legacy resources and manage them however they please with input from this forum. Then there are a lot of folks who?s opinion is that ARIN essentially doesn?t have authority over the Legacy holders resources. Certainly all members of this forum have an equal right to their opinion and an equal right to express them here. I?m not sure which holders of /8?s and other large blocks are still in Legacy status but the list reads like a who?s who of Fortune 500 companies. I don?t ever see comments from those companies stating their opinions in this forum, but you can be sure their attorney?s would have an opinion and would act decisively should ARIN and this forum of Members ever try and reclaim (take) those Legacy resources away from them. As a Legacy holder of one measly /24 block it is my opinion that ARIN and the members of this Forum don?t have the right to just reclaim (take) those resources away from Legacy holders. That is just my opinion and I?m entitled to it - and as a member I can share it in a constructive manner. Based on some off forum email messages I?ve received I think that there are a lot of Members who would completely agree with me. I sense that many have tried in the past to share their view in this forum, and have tired of trying to convince this community to embrace the Legacy community in a reasonable prudent way for all and join with them in ARIN?s mission of furthering Internet usage. Steven - I'm not aware of any policy discussions calling for the reclamation of resources from legacy holders. In fact, such policy discussions are unlikely to be very productive, since the legacy registration agreement contractually precludes reclamation from legacy resource holders; see for details. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From christoph.blecker at ubc.ca Thu Jul 19 22:20:10 2012 From: christoph.blecker at ubc.ca (Blecker, Christoph) Date: Fri, 20 Jul 2012 02:20:10 +0000 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer In-Reply-To: <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> References: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> Message-ID: And then there are those of us who are a little more realistic about things and know that the answer lies somewhere in the middle of those two extremes. Does ARIN have the right? Probably. Would it be good stewardship to start revoking people's resources without an extremely good reason? Absolutely not. Is that what we're talking about? Nope, not at all. Bringing the discussion back to prop-173: I have to think about it a bit more, but I think I could actually get behind a removal for the needs-basis for 8.2 M&A transfers. I think it's silly to drive more distance between "legacy" and "non-legacy" resources, so I wouldn't support that part. If we're going to remove the needs-basis, do it for all resources. It's math.. if you have one company that has a /24 and it buys another company with a /24... if both already have the 80% utilization they need, then the result will still be over 80%. The only time they won't is if one company isn't up to 80% utilization (such as they have legacy resources that don't have this requirement). So ASSUMING that both parties to the M&A are "in compliance" isn't too much of a stretch, really. Removing it, just removes the opportunity to audit the entities as a side effect of an M&A. The reason I'd consider supporting this is because M&A transfers aren't about the number resources. It's a company, buying a whole different company. They're getting a lot more then just the rights to some numbers, they're getting physical assets. This is *VERY* different then 8.3 transfers where you're transferring JUST the numbers without the physical assets. Everything I'm saying here is predicated on the fact that we are talking about an entire company (or at least the networking part with the physical networking assets) being acquired via a merger or acquisition, not number resources that are being monetized by an entity. I'd be interested to know if ARIN staff has any rough numbers about how many M&A transfers have resulted in number resources being returned/reclaimed/aggregated/transferred to bring the entity into compliance. At this time, I don't support as written, but would consider supporting with a removal of all the complicating text about legacy resources and just remove the needs-basis for M&A transfers all together. Cheers, -- Christoph Blecker The University of British Columbia On 2012-07-19, at 5:50 PM, Steven Ryerse wrote: > Viewing posts to this forum over time, I have concluded that there are a lot of folks who?s opinion is that ARIN should just take control of all legacy resources and manage them however they please with input from this forum. Then there are a lot of folks who?s opinion is that ARIN essentially doesn?t have authority over the Legacy holders resources. Certainly all members of this forum have an equal right to their opinion and an equal right to express them here. > > I?m not sure which holders of /8?s and other large blocks are still in Legacy status but the list reads like a who?s who of Fortune 500 companies. I don?t ever see comments from those companies stating their opinions in this forum, but you can be sure their attorney?s would have an opinion and would act decisively should ARIN and this forum of Members ever try and reclaim (take) those Legacy resources away from them. > > As a Legacy holder of one measly /24 block it is my opinion that ARIN and the members of this Forum don?t have the right to just reclaim (take) those resources away from Legacy holders. That is just my opinion and I?m entitled to it - and as a member I can share it in a constructive manner. > > Based on some off forum email messages I?ve received I think that there are a lot of Members who would completely agree with me. I sense that many have tried in the past to share their view in this forum, and have tired of trying to convince this community to embrace the Legacy community in a reasonable prudent way for all and join with them in ARIN?s mission of furthering Internet usage. > > Maybe the prudent thing to do is hold a vote and encourage every member to vote ,even Members that rarely if ever post to this Forum. I?m guessing that there would be a lot of Members voting - and seeing a healthy vote total might be the common ground needed to fairly and prudently address the Legacy holders and non-Legacy Holders need to work together for the common mission. > > I strongly disagree with Larry?s comments but I do share his desire to see this resolved once and for all. > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lindsey, Marc > Sent: Thursday, July 19, 2012 7:17 PM > To: 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer > > Dear Larry, > > You wrote: It seams to me that we will be continually besieged with these proposals . . . . Needless to say I don't support the proposal and am tired of the argument associated with it. I mean no disrespect to Mr. Lindsey but I thought that the list made it's wishes clear before. > > <<< M Lindsey Reply>>> As far as I know, the proposal is still under consideration and has not been abandoned by the AC. There have been both supporters and detractors of the prior drafts. I have read and considered comments from the critics, supporters and ARIN staff, and have revised the proposal text several times in an attempt to address many (but certainly not all) of the concerns raised. > > Notwithstanding your apparent weariness of entertaining viewpoints that differ from your own, in my opinion the PPML is a valuable policy development tool because many on the list (including me) are willing to keep an open mind, revisit their prior assumptions, and consider the merits of contrary arguments. > > But I have noted your general objection to this policy and others like it, and I?ll consider any further responses from you on the topic as a less disrespectful . > > Marc Lindsey > Levine, Blaszak, Block & Boothby, LLP > 2001 L Street, NW Suite 900 > Washington, DC 20036 > Phone: (202) 857-2564 > Email: mlindsey at lb3law.com > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From SRyerse at eclipse-networks.com Thu Jul 19 22:43:30 2012 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Fri, 20 Jul 2012 02:43:30 +0000 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer In-Reply-To: References: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> Message-ID: <5C4532955356D2448E74A170672797E60110E0ED67@ENI-MAIL.eclipse-networks.com> I would just throw this out then, how realistic is it really - for ARIN and this Community to try and manage the Internet number resources for the Americas, when the vast majority of the organizations that hold Legacy assignments - are not participating? Then I would ask, WHY realistically are they not participating? Could it be that they don't trust this Community which is made up of a minority of the organizations utilizing the Internet in the Americas? I can't read their minds but their inaction speaks volumes. So my final question then becomes, realistically - what is the prudent course to get them to participate? That is the course this Community ought to be following. That is the Win-Win-Win situation. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA? 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax ? Eclipse Networks, Inc. ??????? Conquering Complex Networks? -----Original Message----- From: Blecker, Christoph [mailto:christoph.blecker at ubc.ca] Sent: Thursday, July 19, 2012 10:20 PM To: Steven Ryerse Cc: Lindsey, Marc; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer And then there are those of us who are a little more realistic about things and know that the answer lies somewhere in the middle of those two extremes. Does ARIN have the right? Probably. Would it be good stewardship to start revoking people's resources without an extremely good reason? Absolutely not. Is that what we're talking about? Nope, not at all. Bringing the discussion back to prop-173: I have to think about it a bit more, but I think I could actually get behind a removal for the needs-basis for 8.2 M&A transfers. I think it's silly to drive more distance between "legacy" and "non-legacy" resources, so I wouldn't support that part. If we're going to remove the needs-basis, do it for all resources. It's math.. if you have one company that has a /24 and it buys another company with a /24... if both already have the 80% utilization they need, then the result will still be over 80%. The only time they won't is if one company isn't up to 80% utilization (such as they have legacy resources that don't have this requirement). So ASSUMING that both parties to the M&A are "in compliance" isn't too much of a stretch, really. Removing it, just removes the opportunity to audit the entities as a side effect of an M&A. The reason I'd consider supporting this is because M&A transfers aren't about the number resources. It's a company, buying a whole different company. They're getting a lot more then just the rights to some numbers, they're getting physical assets. This is *VERY* different then 8.3 transfers where you're transferring JUST the numbers without the physical assets. Everything I'm saying here is predicated on the fact that we are talking about an entire company (or at least the networking part with the physical networking assets) being acquired via a merger or acquisition, not number resources that are being monetized by an entity. I'd be interested to know if ARIN staff has any rough numbers about how many M&A transfers have resulted in number resources being returned/reclaimed/aggregated/transferred to bring the entity into compliance. At this time, I don't support as written, but would consider supporting with a removal of all the complicating text about legacy resources and just remove the needs-basis for M&A transfers all together. Cheers, -- Christoph Blecker The University of British Columbia On 2012-07-19, at 5:50 PM, Steven Ryerse wrote: > Viewing posts to this forum over time, I have concluded that there are a lot of folks who?s opinion is that ARIN should just take control of all legacy resources and manage them however they please with input from this forum. Then there are a lot of folks who?s opinion is that ARIN essentially doesn?t have authority over the Legacy holders resources. Certainly all members of this forum have an equal right to their opinion and an equal right to express them here. > > I?m not sure which holders of /8?s and other large blocks are still in Legacy status but the list reads like a who?s who of Fortune 500 companies. I don?t ever see comments from those companies stating their opinions in this forum, but you can be sure their attorney?s would have an opinion and would act decisively should ARIN and this forum of Members ever try and reclaim (take) those Legacy resources away from them. > > As a Legacy holder of one measly /24 block it is my opinion that ARIN and the members of this Forum don?t have the right to just reclaim (take) those resources away from Legacy holders. That is just my opinion and I?m entitled to it - and as a member I can share it in a constructive manner. > > Based on some off forum email messages I?ve received I think that there are a lot of Members who would completely agree with me. I sense that many have tried in the past to share their view in this forum, and have tired of trying to convince this community to embrace the Legacy community in a reasonable prudent way for all and join with them in ARIN?s mission of furthering Internet usage. > > Maybe the prudent thing to do is hold a vote and encourage every member to vote ,even Members that rarely if ever post to this Forum. I?m guessing that there would be a lot of Members voting - and seeing a healthy vote total might be the common ground needed to fairly and prudently address the Legacy holders and non-Legacy Holders need to work together for the common mission. > > I strongly disagree with Larry?s comments but I do share his desire to see this resolved once and for all. > > Steven L Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392-0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On Behalf Of Lindsey, Marc > Sent: Thursday, July 19, 2012 7:17 PM > To: 'arin-ppml at arin.net' > Subject: Re: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer > > Dear Larry, > > You wrote: It seams to me that we will be continually besieged with these proposals . . . . Needless to say I don't support the proposal and am tired of the argument associated with it. I mean no disrespect to Mr. Lindsey but I thought that the list made it's wishes clear before. > > <<< M Lindsey Reply>>> As far as I know, the proposal is still under consideration and has not been abandoned by the AC. There have been both supporters and detractors of the prior drafts. I have read and considered comments from the critics, supporters and ARIN staff, and have revised the proposal text several times in an attempt to address many (but certainly not all) of the concerns raised. > > Notwithstanding your apparent weariness of entertaining viewpoints that differ from your own, in my opinion the PPML is a valuable policy development tool because many on the list (including me) are willing to keep an open mind, revisit their prior assumptions, and consider the merits of contrary arguments. > > But I have noted your general objection to this policy and others like it, and I?ll consider any further responses from you on the topic as a less disrespectful . > > Marc Lindsey > Levine, Blaszak, Block & Boothby, LLP > 2001 L Street, NW Suite 900 > Washington, DC 20036 > Phone: (202) 857-2564 > Email: mlindsey at lb3law.com > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From narten at us.ibm.com Fri Jul 20 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 20 Jul 2012 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201207200453.q6K4r2Xk020090@rotala.raleigh.ibm.com> Total of 51 messages in the last 7 days. script run at: Fri Jul 20 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 19.61% | 10 | 15.16% | 83442 | alh-ietf at tndh.net 9.80% | 5 | 16.26% | 89538 | sryerse at eclipse-networks.com 13.73% | 7 | 11.85% | 65231 | farmer at umn.edu 11.76% | 6 | 9.24% | 50861 | owen at delong.com 9.80% | 5 | 10.40% | 57284 | info at arin.net 3.92% | 2 | 8.58% | 47243 | mlindsey at lb3law.com 7.84% | 4 | 4.33% | 23822 | mysidia at gmail.com 3.92% | 2 | 3.82% | 21015 | jcurran at arin.net 1.96% | 1 | 4.10% | 22575 | hannigan at gmail.com 1.96% | 1 | 2.96% | 16300 | babydr at baby-dragons.com 1.96% | 1 | 2.62% | 14402 | lar at mwtcorp.net 1.96% | 1 | 2.32% | 12753 | dogwallah at gmail.com 1.96% | 1 | 2.23% | 12263 | christoph.blecker at ubc.ca 1.96% | 1 | 1.74% | 9573 | jrhett at netconsonance.com 1.96% | 1 | 1.37% | 7568 | george.herbert at gmail.com 1.96% | 1 | 1.17% | 6450 | narten at us.ibm.com 1.96% | 1 | 0.97% | 5316 | jmaimon at chl.com 1.96% | 1 | 0.90% | 4947 | matthew at matthew.at --------+------+--------+----------+------------------------ 100.00% | 51 |100.00% | 550583 | Total From jcurran at arin.net Fri Jul 20 05:55:41 2012 From: jcurran at arin.net (John Curran) Date: Fri, 20 Jul 2012 09:55:41 +0000 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer In-Reply-To: <3070ECE6-D9C3-493E-81DD-3ED0460DF1FD@delong.com> References: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> <0793F933-9856-4041-8450-855DD128F3F9@corp.arin.net> <3070ECE6-D9C3-493E-81DD-3ED0460DF1FD@delong.com> Message-ID: <1EDB79D9-DEED-4F6B-80D7-8D6CA162FD65@arin.net> On Jul 19, 2012, at 11:22 PM, Owen DeLong wrote: On Jul 19, 2012, at 6:57 PM, John Curran wrote: I'm not aware of any policy discussions calling for the reclamation of resources from legacy holders. In fact, such policy discussions are unlikely to be very productive, since the legacy registration agreement contractually precludes reclamation from legacy resource holders; see for details. Does the LRSA preclusion apply to holders that have not signed an agreement with ARIN? Owen - I'm not aware of a process by which a contractual term of the LRSA would apply to parties who haven't executed it. I will note, however, that the ARIN Board has historically set the same practices with respect to those legacy holders who have not signed an LRSA. Clearly, explicit rights via contract are far more tangible. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Fri Jul 20 09:48:07 2012 From: dogwallah at gmail.com (McTim) Date: Fri, 20 Jul 2012 09:48:07 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer In-Reply-To: <5C4532955356D2448E74A170672797E60110E0ECD6@ENI-MAIL.eclipse-networks.com> References: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> <0793F933-9856-4041-8450-855DD128F3F9@corp.arin.net> <5C4532955356D2448E74A170672797E60110E0ECD6@ENI-MAIL.eclipse-networks.com> Message-ID: Hi, On Thu, Jul 19, 2012 at 10:14 PM, Steven Ryerse < SRyerse at eclipse-networks.com> wrote: > I appreciate the input! I?ve read thru that section and it is helpful. > Unfortunately there appear to be Members who would prefer to have ARIN just > reclaim all Legacy resources unilaterally. > Could you point to a post on the list that advocates this? I don't recall any. > I understand that a Legacy holder can decide to sign the LSRA, but if > they elect not to for whatever reason(s) - hopefully this ?Community? will > never decide at some point to change ARINs policies to allow reclaiming > Legacy resources unilaterally. This is less likely while ARIN still has > IPv4 Addresses & AS numbers to assign, but once they are gone, there is no > guarantee that cooler heads will prevail. It would be good if this issue > was fully addressed once and for all. > I have my doubts that we will ever see such a resolution, but YMMV of course. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Fri Jul 20 09:54:24 2012 From: dogwallah at gmail.com (McTim) Date: Fri, 20 Jul 2012 09:54:24 -0400 Subject: [arin-ppml] ARIN-prop-173 Revisions to M&A Transfer In-Reply-To: <5C4532955356D2448E74A170672797E60110E0ED67@ENI-MAIL.eclipse-networks.com> References: <98E8C412B2F47D48A79816422B860E1B04B9EC92BFA8@lb3ex01> <98E8C412B2F47D48A79816422B860E1B04B9EC926F7E@lb3ex01> <5C4532955356D2448E74A170672797E60110E0EB65@ENI-MAIL.eclipse-networks.com> <5C4532955356D2448E74A170672797E60110E0ED67@ENI-MAIL.eclipse-networks.com> Message-ID: On Thu, Jul 19, 2012 at 10:43 PM, Steven Ryerse wrote: > I would just throw this out then, how realistic is it really - for ARIN and this Community to try and manage the Internet number resources for the Americas, when the vast majority of the organizations that hold Legacy assignments - are not participating? Do you have any evidence to back up this assertion? > Then I would ask, WHY realistically are they not participating? Could it be that they don't trust this Community which is made up of a minority of the organizations utilizing the Internet in the Americas? I think the ARIN community will ALWAYS be a "minority of the organizations utilizing the Internet in the Americas"...if a majority of folk who use the Internet in the ARIN region were on the lists/went to an ARIN meeting, we would need to hold meeting is large stadia! > I can't read their minds but their inaction speaks volumes. I am not sure you can infer exactly what they are saying, I suspect they either don't know or are unconcerned as is the case with the vast majority "of the organizations utilizing the Internet in the Americas" > So my final question then becomes, realistically - what is the prudent course to get them to participate? That is the course this Community ought to be following. Not at the cost of abandoning our other obligations in re; stewardship of resources IMHO. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From cb.list6 at gmail.com Fri Jul 20 10:55:42 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 20 Jul 2012 07:55:42 -0700 Subject: [arin-ppml] Residential Customers Message-ID: Dear PPML, Are mobile network subscribers considered residential customers? https://www.arin.net/policy/nrpm.html#two13 2.13. Residential Customer End-users who are individual persons and not organizations and who receive service at a place of residence for personal use only are considered residential customers. I would say yes. There is no meaningful distinction from a IP resource utilization perspective, a cable CMTS is nearly equivalent to a mobile GGSN / PDSN, no? Mobile subscribers are certainly not "ISPs", they do no sub-delegate... or even "Enterprise Networks" ... mobile subscribers are 1 IP per subscription. How should ARIN staff be interpreting this term "Residential Customer" with regards to mobile network? Are they or are they not "residential customers"? Thanks, Cameron From scottleibrand at gmail.com Fri Jul 20 12:16:50 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 20 Jul 2012 09:16:50 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: Message-ID: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> I would say yes, a natural person qualifies as a residential customer. If ARIN interprets the policy differently, we can of course make the policy more explicit. Scott On Jul 20, 2012, at 7:55 AM, Cameron Byrne wrote: > Dear PPML, > > Are mobile network subscribers considered residential customers? > > https://www.arin.net/policy/nrpm.html#two13 > > 2.13. Residential Customer > > End-users who are individual persons and not organizations and who > receive service at a place of residence for personal use only are > considered residential customers. > > I would say yes. There is no meaningful distinction from a IP > resource utilization perspective, a cable CMTS is nearly equivalent > to a mobile GGSN / PDSN, no? > > Mobile subscribers are certainly not "ISPs", they do no > sub-delegate... or even "Enterprise Networks" ... mobile subscribers > are 1 IP per subscription. > > How should ARIN staff be interpreting this term "Residential Customer" > with regards to mobile network? Are they or are they not "residential > customers"? > > Thanks, > > Cameron > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From heather.skanks at gmail.com Fri Jul 20 12:23:28 2012 From: heather.skanks at gmail.com (Heather Schiller) Date: Fri, 20 Jul 2012 12:23:28 -0400 Subject: [arin-ppml] Residential Customers In-Reply-To: References: Message-ID: If you are referring to SWIP requirements for residential subscribers (and that ISP's may keep them private) -- don't most mobile subscribers get dynamically assigned IP's or exist behind a NAT? In those cases you wouldn't SWIP to an individual anyway. --Heather On Fri, Jul 20, 2012 at 10:55 AM, Cameron Byrne wrote: > Dear PPML, > > Are mobile network subscribers considered residential customers? > > https://www.arin.net/policy/nrpm.html#two13 > > 2.13. Residential Customer > > End-users who are individual persons and not organizations and who > receive service at a place of residence for personal use only are > considered residential customers. > > I would say yes. There is no meaningful distinction from a IP > resource utilization perspective, a cable CMTS is nearly equivalent > to a mobile GGSN / PDSN, no? > > Mobile subscribers are certainly not "ISPs", they do no > sub-delegate... or even "Enterprise Networks" ... mobile subscribers > are 1 IP per subscription. > > How should ARIN staff be interpreting this term "Residential Customer" > with regards to mobile network? Are they or are they not "residential > customers"? > > Thanks, > > Cameron > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From cb.list6 at gmail.com Fri Jul 20 13:06:16 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 20 Jul 2012 10:06:16 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: On Fri, Jul 20, 2012 at 9:16 AM, Scott Leibrand wrote: > I would say yes, a natural person qualifies as a residential customer. If ARIN interprets the policy differently, we can of course make the policy more explicit. > > Scott > Yes, ARIN has informed me that since the service is not to PHYSICAL residence, it does not apply. This seemed strange to me, not sure why IP policy would apply to OSI Layer 1 media type. Is an official wording change required or just guidance to the ARIN staff? CB > On Jul 20, 2012, at 7:55 AM, Cameron Byrne wrote: > >> Dear PPML, >> >> Are mobile network subscribers considered residential customers? >> >> https://www.arin.net/policy/nrpm.html#two13 >> >> 2.13. Residential Customer >> >> End-users who are individual persons and not organizations and who >> receive service at a place of residence for personal use only are >> considered residential customers. >> >> I would say yes. There is no meaningful distinction from a IP >> resource utilization perspective, a cable CMTS is nearly equivalent >> to a mobile GGSN / PDSN, no? >> >> Mobile subscribers are certainly not "ISPs", they do no >> sub-delegate... or even "Enterprise Networks" ... mobile subscribers >> are 1 IP per subscription. >> >> How should ARIN staff be interpreting this term "Residential Customer" >> with regards to mobile network? Are they or are they not "residential >> customers"? >> >> Thanks, >> >> Cameron >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. From cgrundemann at gmail.com Fri Jul 20 13:09:14 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 20 Jul 2012 11:09:14 -0600 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: On Fri, Jul 20, 2012 at 11:06 AM, Cameron Byrne wrote: > On Fri, Jul 20, 2012 at 9:16 AM, Scott Leibrand wrote: >> I would say yes, a natural person qualifies as a residential customer. If ARIN interprets the policy differently, we can of course make the policy more explicit. >> >> Scott >> > > > Yes, ARIN has informed me that since the service is not to PHYSICAL > residence, it does not apply. > > This seemed strange to me, not sure why IP policy would apply to OSI > Layer 1 media type. Is an official wording change required or just > guidance to the ARIN staff? In what context did they say this? What specifically are we talking about (in what way do you need "residential customer" to apply)? ~Chris > CB > > >> On Jul 20, 2012, at 7:55 AM, Cameron Byrne wrote: >> >>> Dear PPML, >>> >>> Are mobile network subscribers considered residential customers? >>> >>> https://www.arin.net/policy/nrpm.html#two13 >>> >>> 2.13. Residential Customer >>> >>> End-users who are individual persons and not organizations and who >>> receive service at a place of residence for personal use only are >>> considered residential customers. >>> >>> I would say yes. There is no meaningful distinction from a IP >>> resource utilization perspective, a cable CMTS is nearly equivalent >>> to a mobile GGSN / PDSN, no? >>> >>> Mobile subscribers are certainly not "ISPs", they do no >>> sub-delegate... or even "Enterprise Networks" ... mobile subscribers >>> are 1 IP per subscription. >>> >>> How should ARIN staff be interpreting this term "Residential Customer" >>> with regards to mobile network? Are they or are they not "residential >>> customers"? >>> >>> Thanks, >>> >>> Cameron >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- @ChrisGrundemann http://chrisgrundemann.com From cb.list6 at gmail.com Fri Jul 20 13:10:06 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 20 Jul 2012 10:10:06 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: Message-ID: On Fri, Jul 20, 2012 at 9:23 AM, Heather Schiller wrote: > If you are referring to SWIP requirements for residential subscribers > (and that ISP's may keep them private) -- don't most mobile > subscribers get dynamically assigned IP's or exist behind a NAT? In > those cases you wouldn't SWIP to an individual anyway. > Yes, most mobile subscribers get dynamic IP addresses, which is the same for most Cable and DSL subscribers. NAT is a separate matter which is not considered / required in NRPM. CB > --Heather > > On Fri, Jul 20, 2012 at 10:55 AM, Cameron Byrne wrote: >> Dear PPML, >> >> Are mobile network subscribers considered residential customers? >> >> https://www.arin.net/policy/nrpm.html#two13 >> >> 2.13. Residential Customer >> >> End-users who are individual persons and not organizations and who >> receive service at a place of residence for personal use only are >> considered residential customers. >> >> I would say yes. There is no meaningful distinction from a IP >> resource utilization perspective, a cable CMTS is nearly equivalent >> to a mobile GGSN / PDSN, no? >> >> Mobile subscribers are certainly not "ISPs", they do no >> sub-delegate... or even "Enterprise Networks" ... mobile subscribers >> are 1 IP per subscription. >> >> How should ARIN staff be interpreting this term "Residential Customer" >> with regards to mobile network? Are they or are they not "residential >> customers"? >> >> Thanks, >> >> Cameron >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. From cb.list6 at gmail.com Fri Jul 20 13:17:20 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 20 Jul 2012 10:17:20 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: On Fri, Jul 20, 2012 at 10:09 AM, Chris Grundemann wrote: > On Fri, Jul 20, 2012 at 11:06 AM, Cameron Byrne wrote: >> On Fri, Jul 20, 2012 at 9:16 AM, Scott Leibrand wrote: >>> I would say yes, a natural person qualifies as a residential customer. If ARIN interprets the policy differently, we can of course make the policy more explicit. >>> >>> Scott >>> >> >> >> Yes, ARIN has informed me that since the service is not to PHYSICAL >> residence, it does not apply. >> >> This seemed strange to me, not sure why IP policy would apply to OSI >> Layer 1 media type. Is an official wording change required or just >> guidance to the ARIN staff? > > In what context did they say this? What specifically are we talking > about (in what way do you need "residential customer" to apply)? > Very specifically, i was told that i must show specifically 80% active usage of all assigned addresses. I would like to move the bar from 80% demonstrated active use to 50% use as defined here in NRPM 4.2.3.7.3.1. The technical issues that, i assume, prompted policy in NRPM 4.2.3.7.3.1. applies the same way to mobile networks as it does to landline, thus the policy should apply the same when requesting resources and justifying use. CB > ~Chris > >> CB >> >> >>> On Jul 20, 2012, at 7:55 AM, Cameron Byrne wrote: >>> >>>> Dear PPML, >>>> >>>> Are mobile network subscribers considered residential customers? >>>> >>>> https://www.arin.net/policy/nrpm.html#two13 >>>> >>>> 2.13. Residential Customer >>>> >>>> End-users who are individual persons and not organizations and who >>>> receive service at a place of residence for personal use only are >>>> considered residential customers. >>>> >>>> I would say yes. There is no meaningful distinction from a IP >>>> resource utilization perspective, a cable CMTS is nearly equivalent >>>> to a mobile GGSN / PDSN, no? >>>> >>>> Mobile subscribers are certainly not "ISPs", they do no >>>> sub-delegate... or even "Enterprise Networks" ... mobile subscribers >>>> are 1 IP per subscription. >>>> >>>> How should ARIN staff be interpreting this term "Residential Customer" >>>> with regards to mobile network? Are they or are they not "residential >>>> customers"? >>>> >>>> Thanks, >>>> >>>> Cameron >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > -- > @ChrisGrundemann > http://chrisgrundemann.com From cgrundemann at gmail.com Fri Jul 20 14:22:41 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 20 Jul 2012 12:22:41 -0600 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: On Fri, Jul 20, 2012 at 11:17 AM, Cameron Byrne wrote: > On Fri, Jul 20, 2012 at 10:09 AM, Chris Grundemann > wrote: >> On Fri, Jul 20, 2012 at 11:06 AM, Cameron Byrne wrote: >>> On Fri, Jul 20, 2012 at 9:16 AM, Scott Leibrand wrote: >>>> I would say yes, a natural person qualifies as a residential customer. If ARIN interprets the policy differently, we can of course make the policy more explicit. >>>> >>>> Scott >>>> >>> >>> >>> Yes, ARIN has informed me that since the service is not to PHYSICAL >>> residence, it does not apply. >>> >>> This seemed strange to me, not sure why IP policy would apply to OSI >>> Layer 1 media type. Is an official wording change required or just >>> guidance to the ARIN staff? >> >> In what context did they say this? What specifically are we talking >> about (in what way do you need "residential customer" to apply)? >> > > Very specifically, i was told that i must show specifically 80% active > usage of all assigned addresses. > > I would like to move the bar from 80% demonstrated active use to 50% > use as defined here in NRPM 4.2.3.7.3.1. > > The technical issues that, i assume, prompted policy in NRPM > 4.2.3.7.3.1. applies the same way to mobile networks as it does to > landline, thus the policy should apply the same when requesting > resources and justifying use. The only issue I see is that many (all that I have personal knowledge of) mobile providers NAT most (if not all) of their customer traffic (ala CGN, before it had a cool name) and often mix private addresses in with the public to expand the use of address pools when needed (since its all NATed anyway, it doesn't matter). In that environment, a 50% utilization rate almost becomes a license to steal. I think we need to assure that free pool public addresses go where they are most needed and don't end up in NAT pools where globally unique addresses are not required. I think the community would need some kind of assurance around that for this to work... But I could be way off base, I'm sure folks will tell me if I am. ~Chris > > CB > > >> ~Chris >> >>> CB >>> >>> >>>> On Jul 20, 2012, at 7:55 AM, Cameron Byrne wrote: >>>> >>>>> Dear PPML, >>>>> >>>>> Are mobile network subscribers considered residential customers? >>>>> >>>>> https://www.arin.net/policy/nrpm.html#two13 >>>>> >>>>> 2.13. Residential Customer >>>>> >>>>> End-users who are individual persons and not organizations and who >>>>> receive service at a place of residence for personal use only are >>>>> considered residential customers. >>>>> >>>>> I would say yes. There is no meaningful distinction from a IP >>>>> resource utilization perspective, a cable CMTS is nearly equivalent >>>>> to a mobile GGSN / PDSN, no? >>>>> >>>>> Mobile subscribers are certainly not "ISPs", they do no >>>>> sub-delegate... or even "Enterprise Networks" ... mobile subscribers >>>>> are 1 IP per subscription. >>>>> >>>>> How should ARIN staff be interpreting this term "Residential Customer" >>>>> with regards to mobile network? Are they or are they not "residential >>>>> customers"? >>>>> >>>>> Thanks, >>>>> >>>>> Cameron >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> >> >> -- >> @ChrisGrundemann >> http://chrisgrundemann.com -- @ChrisGrundemann http://chrisgrundemann.com From cb.list6 at gmail.com Fri Jul 20 14:31:09 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 20 Jul 2012 11:31:09 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: On Fri, Jul 20, 2012 at 11:22 AM, Chris Grundemann wrote: > On Fri, Jul 20, 2012 at 11:17 AM, Cameron Byrne wrote: >> On Fri, Jul 20, 2012 at 10:09 AM, Chris Grundemann >> wrote: >>> On Fri, Jul 20, 2012 at 11:06 AM, Cameron Byrne wrote: >>>> On Fri, Jul 20, 2012 at 9:16 AM, Scott Leibrand wrote: >>>>> I would say yes, a natural person qualifies as a residential customer. If ARIN interprets the policy differently, we can of course make the policy more explicit. >>>>> >>>>> Scott >>>>> >>>> >>>> >>>> Yes, ARIN has informed me that since the service is not to PHYSICAL >>>> residence, it does not apply. >>>> >>>> This seemed strange to me, not sure why IP policy would apply to OSI >>>> Layer 1 media type. Is an official wording change required or just >>>> guidance to the ARIN staff? >>> >>> In what context did they say this? What specifically are we talking >>> about (in what way do you need "residential customer" to apply)? >>> >> >> Very specifically, i was told that i must show specifically 80% active >> usage of all assigned addresses. >> >> I would like to move the bar from 80% demonstrated active use to 50% >> use as defined here in NRPM 4.2.3.7.3.1. >> >> The technical issues that, i assume, prompted policy in NRPM >> 4.2.3.7.3.1. applies the same way to mobile networks as it does to >> landline, thus the policy should apply the same when requesting >> resources and justifying use. > > The only issue I see is that many (all that I have personal knowledge > of) mobile providers NAT most (if not all) of their customer traffic > (ala CGN, before it had a cool name) and often mix private addresses > in with the public to expand the use of address pools when needed > (since its all NATed anyway, it doesn't matter). In that environment, > a 50% utilization rate almost becomes a license to steal. I think we > need to assure that free pool public addresses go where they are most > needed and don't end up in NAT pools where globally unique addresses > are not required. I think the community would need some kind of > assurance around that for this to work... But I could be way off base, > I'm sure folks will tell me if I am. > > ~Chris > That sounds like new policy, a specific policy for CGN infrastructure. My question was around existing policy and the definition of residential. I am sure you also know some large DSL providers are now using private space for their customers and deploying CGN. FYI, my situation / request is for end-user IP addresses assigned to end users dynamically (similar to status quo with other residential services such as Cable and DSL). This is not space assigned to CGN or infrastructure. CB >> >> CB >> >> >>> ~Chris >>> >>>> CB >>>> >>>> >>>>> On Jul 20, 2012, at 7:55 AM, Cameron Byrne wrote: >>>>> >>>>>> Dear PPML, >>>>>> >>>>>> Are mobile network subscribers considered residential customers? >>>>>> >>>>>> https://www.arin.net/policy/nrpm.html#two13 >>>>>> >>>>>> 2.13. Residential Customer >>>>>> >>>>>> End-users who are individual persons and not organizations and who >>>>>> receive service at a place of residence for personal use only are >>>>>> considered residential customers. >>>>>> >>>>>> I would say yes. There is no meaningful distinction from a IP >>>>>> resource utilization perspective, a cable CMTS is nearly equivalent >>>>>> to a mobile GGSN / PDSN, no? >>>>>> >>>>>> Mobile subscribers are certainly not "ISPs", they do no >>>>>> sub-delegate... or even "Enterprise Networks" ... mobile subscribers >>>>>> are 1 IP per subscription. >>>>>> >>>>>> How should ARIN staff be interpreting this term "Residential Customer" >>>>>> with regards to mobile network? Are they or are they not "residential >>>>>> customers"? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Cameron >>>>>> _______________________________________________ >>>>>> PPML >>>>>> You are receiving this message because you are subscribed to >>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> >>> >>> >>> -- >>> @ChrisGrundemann >>> http://chrisgrundemann.com > > > > -- > @ChrisGrundemann > http://chrisgrundemann.com From scottleibrand at gmail.com Fri Jul 20 14:58:10 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 20 Jul 2012 11:58:10 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: On Fri, Jul 20, 2012 at 10:17 AM, Cameron Byrne wrote: > On Fri, Jul 20, 2012 at 10:09 AM, Chris Grundemann > wrote: > > On Fri, Jul 20, 2012 at 11:06 AM, Cameron Byrne > wrote: > >> On Fri, Jul 20, 2012 at 9:16 AM, Scott Leibrand < > scottleibrand at gmail.com> wrote: > >>> I would say yes, a natural person qualifies as a residential customer. > If ARIN interprets the policy differently, we can of course make the policy > more explicit. > >>> > >>> Scott > >>> > >> > >> > >> Yes, ARIN has informed me that since the service is not to PHYSICAL > >> residence, it does not apply. > >> > >> This seemed strange to me, not sure why IP policy would apply to OSI > >> Layer 1 media type. Is an official wording change required or just > >> guidance to the ARIN staff? > > > > In what context did they say this? What specifically are we talking > > about (in what way do you need "residential customer" to apply)? > > > > Very specifically, i was told that i must show specifically 80% active > usage of all assigned addresses. > > I would like to move the bar from 80% demonstrated active use to 50% > use as defined here in NRPM 4.2.3.7.3.1. > > The technical issues that, i assume, prompted policy in NRPM > 4.2.3.7.3.1. applies the same way to mobile networks as it does to > landline, thus the policy should apply the same when requesting > resources and justifying use. > I think the simplest change that would accomplish this would be to add "or mobile" to the second paragraph of 4.2.3.7.3.1. It would then read: Using SWIP or RWhois, residential or mobile access ISPs must show that they have reassigned at least 80% of their current address space, with a 50 to 80% utilization rate, in order to request additional addresses. I don't think the first paragraph needs to change, because the "Initial allocations are based on total number of homes that could purchase the service in a given market area" text would not seem to apply to mobile technology. Is that what you're looking for? If so, feel free to submit it as a proposal to policy at arin.net. I'll be happy to assist in any way I can. I'm sure such a change will prompt lots of discussion, and I think a concrete policy proposal will help frame that discussion. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Fri Jul 20 15:03:12 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 20 Jul 2012 12:03:12 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: On Fri, Jul 20, 2012 at 11:58 AM, Scott Leibrand wrote: > On Fri, Jul 20, 2012 at 10:17 AM, Cameron Byrne wrote: >> >> On Fri, Jul 20, 2012 at 10:09 AM, Chris Grundemann >> wrote: >> > On Fri, Jul 20, 2012 at 11:06 AM, Cameron Byrne >> > wrote: >> >> On Fri, Jul 20, 2012 at 9:16 AM, Scott Leibrand >> >> wrote: >> >>> I would say yes, a natural person qualifies as a residential customer. >> >>> If ARIN interprets the policy differently, we can of course make the policy >> >>> more explicit. >> >>> >> >>> Scott >> >>> >> >> >> >> >> >> Yes, ARIN has informed me that since the service is not to PHYSICAL >> >> residence, it does not apply. >> >> >> >> This seemed strange to me, not sure why IP policy would apply to OSI >> >> Layer 1 media type. Is an official wording change required or just >> >> guidance to the ARIN staff? >> > >> > In what context did they say this? What specifically are we talking >> > about (in what way do you need "residential customer" to apply)? >> > >> >> Very specifically, i was told that i must show specifically 80% active >> usage of all assigned addresses. >> >> I would like to move the bar from 80% demonstrated active use to 50% >> use as defined here in NRPM 4.2.3.7.3.1. >> >> The technical issues that, i assume, prompted policy in NRPM >> 4.2.3.7.3.1. applies the same way to mobile networks as it does to >> landline, thus the policy should apply the same when requesting >> resources and justifying use. > > > I think the simplest change that would accomplish this would be to add "or > mobile" to the second paragraph of 4.2.3.7.3.1. It would then read: > > Using SWIP or RWhois, residential or mobile access ISPs must show that they > have reassigned at least 80% of their current address space, with a 50 to > 80% utilization rate, in order to request additional addresses. > > I don't think the first paragraph needs to change, because the "Initial > allocations are based on total number of homes that could purchase the > service in a given market area" text would not seem to apply to mobile > technology. > > Is that what you're looking for? If so, feel free to submit it as a > proposal to policy at arin.net. I'll be happy to assist in any way I can. > > I'm sure such a change will prompt lots of discussion, and I think a > concrete policy proposal will help frame that discussion. > > -Scott My hope is that the wording does not have to change. I believe the "spirit" of the policy is that a "consumer service" = "residential service" = "mobile service". The main point being that an single ARIN IP address is dynamically allocated to a user for personal connectivity. As others have mentioned, can staff guidance be enough? If so, how does staff get guidance? CB From jrhett at netconsonance.com Fri Jul 20 16:12:08 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 20 Jul 2012 13:12:08 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: <87C43A27-9D27-49A0-B735-1C5396F7C21F@netconsonance.com> On Jul 20, 2012, at 12:03 PM, Cameron Byrne wrote: > I believe the "spirit" of the policy is that a "consumer service" = > "residential service" = "mobile service". The main point being that > an single ARIN IP address is dynamically allocated to a user for > personal connectivity. Your simplification is not the reality on the ground. Many residential services are classified as business services simply to receive static IPs necessary for VPN access to their employer or client -- or even for running gaming servers. Second, your attempt to suggest "one user == one IP" is way stuck in the 1980s. I have almost a dozen real addresses assigned to just me at any given time. Two cell phones (three when I'm On Point at work) and two tablet devices have public IPs. My residential /29 at one house and a /32 at another. Plus my laptop is usually bound to SJ Wifi with a public IP, or bound to a home or cafe site. This doesn't even account for each website I run with SSL support, which would push my "personal" use well past a /27. And that's not accounting for a few businesses which I'm deeply involved in. I believe that any attempt to codify a user -> use mapping is doomed to failure. Even if you got it right today, expectations would be nonsense within a few years. 20 years ago we assumed one user, one computer, one IP. Today our office witnesses a minimum of 3 and an average of 6 IPs per user. (nobody here has less than a desktop, phone and smartphone -- most also have a laptop, tablet, and one or more testing devices at any time) -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrhett at netconsonance.com Fri Jul 20 15:54:21 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 20 Jul 2012 12:54:21 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: <244986CF-8231-4527-B947-D0E50463E160@netconsonance.com> On Jul 20, 2012, at 11:58 AM, Scott Leibrand wrote: > Using SWIP or RWhois, residential or mobile access ISPs must show that they have reassigned at least 80% of their current address space, with a 50 to 80% utilization rate, in order to request additional addresses. How is that not simply 50% ? And honestly, I love this policy. I have a /21 assigned, I fill half of it and I get get another /21! Sweet! I support the 80% policy as it stands. ARIN already has rules that account for geographic limitations that can (and have for me) help justification when it's not technically possible to subnet the block. If you don't have a geographical/physically problem then you can work around this issue. I'd support 90% rule for wireless access providers, to be honest. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lar at mwtcorp.net Fri Jul 20 17:04:20 2012 From: lar at mwtcorp.net (Larry Ash) Date: Fri, 20 Jul 2012 15:04:20 -0600 Subject: [arin-ppml] Residential Customers In-Reply-To: <244986CF-8231-4527-B947-D0E50463E160@netconsonance.com> References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> <244986CF-8231-4527-B947-D0E50463E160@netconsonance.com> Message-ID: On Fri, 20 Jul 2012 12:54:21 -0700 Jo Rhett wrote: > On Jul 20, 2012, at 11:58 AM, Scott Leibrand wrote: >> Using SWIP or RWhois, residential or mobile access ISPs must show that they >>have reassigned at least 80% of their current address space, with a 50 to 80% >>utilization rate, in order to request additional addresses. > > How is that not simply 50% ? > > > And honestly, I love this policy. I have a /21 assigned, I fill half of it >and I get get another /21! Sweet! > > > I support the 80% policy as it stands. ARIN already has rules that account >for geographic limitations that can (and have for me) help justification when >it's not technically possible to subnet the block. If you don't have a >geographical/physically problem then you can work around this issue. I'd >support 90% rule for wireless access providers, to be honest. > I am suspicious that we have a little bit of apples and oranges going on. Lets say I am a wireless provider (I am) and I have a /20 which has more than 80% of the address reassigned/allocated and in "use" and am preparing to request another allocation. Further let's say that when looking at how the addresses are being used there are a number of towers that have /27's assigned to each sector. As I read it, the original question seemed to assume that each sector's /27 needed to be 80% utilized. That seems to me to be very difficult if not impossible. Since the choice is /28 or /27 if a /28 is too small then a /27 is appropriate. The question I have is are we having to get to this detail, (I assume we are) and even if we are do we really want to tell operators that they have to renumber their affected customers when they go from 14 to 15 customers on a sector or tell him that he needs to use layer 2 transport instead of subnetting on a sector basis which seems to me to be a design choice beyond our scope. As bandwidth requirements have risen the number of customers on a single sector has fallen so this kind of problem is more likely now than in the past. If that is not what the original poster meant please correct me. > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet >projects. > > > Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From jrhett at netconsonance.com Fri Jul 20 18:43:53 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 20 Jul 2012 15:43:53 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> <244986CF-8231-4527-B947-D0E50463E160@netconsonance.com> Message-ID: <2B3B69EE-ED9D-494C-BF30-793EC0667C6F@netconsonance.com> On Jul 20, 2012, at 2:20 PM, Andrew Koch wrote: > On Fri, Jul 20, 2012 at 2:54 PM, Jo Rhett wrote: >> >> Using SWIP or RWhois, residential or mobile access ISPs must show that they >> have reassigned at least 80% of their current address space, with a 50 to >> 80% utilization rate, in order to request additional addresses. >> >> How is that not simply 50% ? > > I have assigned 80% to pools, but the pools only need to be filled to > 50% before working toward the next resource request. Um, then I can get a /20 and get another when I've used a /22! Do the math. That's barely getting started. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrhett at netconsonance.com Fri Jul 20 18:46:48 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Fri, 20 Jul 2012 15:46:48 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> <244986CF-8231-4527-B947-D0E50463E160@netconsonance.com> Message-ID: <49A66E47-95C4-41F6-9918-DFD5B9B467F7@netconsonance.com> On Jul 20, 2012, at 2:04 PM, Larry Ash wrote: > As I read it, the original question seemed to assume that each sector's /27 needed > to be 80% utilized. That seems to me to be very difficult if not impossible. You haven't read the documents. The rules in place already account for this under geographic diversity. Loosening it within requiring the diversity requirements would allow widespread abuse. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Fri Jul 20 22:04:05 2012 From: dogwallah at gmail.com (McTim) Date: Fri, 20 Jul 2012 22:04:05 -0400 Subject: [arin-ppml] Residential Customers In-Reply-To: <244986CF-8231-4527-B947-D0E50463E160@netconsonance.com> References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> <244986CF-8231-4527-B947-D0E50463E160@netconsonance.com> Message-ID: On Fri, Jul 20, 2012 at 3:54 PM, Jo Rhett wrote: > On Jul 20, 2012, at 11:58 AM, Scott Leibrand wrote: > > Using SWIP or RWhois, residential or mobile access ISPs must show that they > have reassigned at least 80% of their current address space, with a 50 to > 80% utilization rate, in order to request additional addresses. > > > How is that not simply 50% ? > > > And honestly, I love this policy. I have a /21 assigned, I fill half of it > and I get get another /21! Sweet! > > > I support the 80% policy as it stands. ARIN already has rules that account > for geographic limitations that can (and have for me) help justification > when it's not technically possible to subnet the block. If you don't have a > geographical/physically problem then you can work around this issue. I'd > support 90% rule for wireless access providers, to be honest. I agree with all of Jo's points above. Why would changing policy be easier than just showing hostmasters/Resource Analysts that you are actually using the IPs that you are using? MRTG/other tools can be configged to do this...just send them a graph and you are sorted, no need to list actual people! -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From mysidia at gmail.com Fri Jul 20 22:20:40 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 20 Jul 2012 21:20:40 -0500 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> <244986CF-8231-4527-B947-D0E50463E160@netconsonance.com> Message-ID: On 7/20/12, McTim wrote: > I agree with all of Jo's points above. > Why would changing policy be easier than just showing hostmasters/Resource > Analysts that you are actually using the IPs that you are using? Right... This policy was not intended to apply to "Mobile services" This policy was meant to apply to residential services. In light of impending exhaustion, however, 50% utilization may be too lax. Suggested change: https://www.arin.net/policy/nrpm.html#four23731 Revise 4.2.3.7.3.1 Replace "reassigned at least 80% of their current address space, with a 50 to 80% utilization rate, in order to request additional addresses." With: "reassigned at least 80% of their current address space, with a minimum utilization rate of 80%, in order to request additional addresses." -- -JH From cgrundemann at gmail.com Fri Jul 20 22:27:05 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 20 Jul 2012 20:27:05 -0600 Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 In-Reply-To: <50085F78.7010802@chl.com> References: <50085F78.7010802@chl.com> Message-ID: On Thu, Jul 19, 2012 at 1:26 PM, Joe Maimon wrote: > All, > > Policy Proposal #168 Promote 4byte ASN Usage, was intended to deal with the > lack of uptake of 4byte ASN as well as the continued demand for 2byte ASN. > > It does so by expanding on the capabilities of both the community and ARIN > with regards to ASN policy. Hi Joe, Perhaps if you more fully explain how this policy change would deal with the lack of uptale of 4byte ASN (how specifically it differs from current ARIN practice and how those changes "Promote 4byte ASN Usage") more folks would be more in favor of it (and of your petition). I personally have not been able to parse that myself and so it may be possible that others are in the same boat. Just a thought. Cheers, ~Chris > I believe that more discussion on this topic is warranted. ARIN Staff said > as much at previous PPM and I was hoping that this proposal would help do > that. > > As such, the AC's abandonment of this proposal was disappointing to me. > > While it may not be as compelling and controversial as some of the topics > swirling through the list these days, ASN policy is important, > disproportionately so, to the newcomers of our community. > > I formally petition you, the members of this community, for your support in > advancing to draft policy status the proposal and for it to be discussed at > an upcoming ARIN Public Policy meeting. > > I ask you for statements in support of this petition. > > The full policy proposal text is available at > > http://lists.arin.net/pipermail/arin-ppml/2012-May/024892.html > > Best and my thanks, > > Joe > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- @ChrisGrundemann http://chrisgrundemann.com From dave at temk.in Mon Jul 23 16:13:58 2012 From: dave at temk.in (David Temkin) Date: Mon, 23 Jul 2012 16:13:58 -0400 Subject: [arin-ppml] Reminder: Call for Presentations Open for NANOG 56 in Dallas, TX Message-ID: <500DB086.8010303@temk.in> NANOG Community, After a great NANOG in Vancouver, BC, the survey results are in from 55 and we are already assembling a world-class program for NANOG 56. The North American Network Operators' Group (NANOG) will hold its 56th meeting in Dallas, TX on October 21 - 23, 2012 and join with ARIN on October 24, 2012. Terremark, a Verzion company, will be our host for NANOG 56. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 56 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet. Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. NANOG 56 submissions are welcome at http://pc.nanog.org For further information on what the Program Committee is seeking, please see http://www.nanog.org/meetings/nanog56/callforpresentations.html When considering submitting a presentation, keep these important dates in mind: Presentation Abstracts and Draft Slides Due: 06-August-2012 Final Slides Due: 27-August-2012 Draft Program Published: 17-September-2012 Final Agenda Published: 1-October-2012 Please submit your materials to http://pc.nanog.org Looking forward to seeing everyone in Dallas! -Dave Temkin (Chair, NANOG Program Committee) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Tue Jul 24 22:35:51 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 24 Jul 2012 19:35:51 -0700 Subject: [arin-ppml] Residential Customers In-Reply-To: References: <3335724F-2387-4BBC-B65B-0E54F7B95DF2@gmail.com> Message-ID: On Fri, Jul 20, 2012 at 10:33 AM, Owen DeLong wrote: > > On Jul 20, 2012, at 10:17 AM, Cameron Byrne wrote: > >> On Fri, Jul 20, 2012 at 10:09 AM, Chris Grundemann >> wrote: >>> On Fri, Jul 20, 2012 at 11:06 AM, Cameron Byrne wrote: >>>> On Fri, Jul 20, 2012 at 9:16 AM, Scott Leibrand wrote: >>>>> I would say yes, a natural person qualifies as a residential customer. If ARIN interprets the policy differently, we can of course make the policy more explicit. >>>>> >>>>> Scott >>>>> >>>> >>>> >>>> Yes, ARIN has informed me that since the service is not to PHYSICAL >>>> residence, it does not apply. >>>> >>>> This seemed strange to me, not sure why IP policy would apply to OSI >>>> Layer 1 media type. Is an official wording change required or just >>>> guidance to the ARIN staff? >>> >>> In what context did they say this? What specifically are we talking >>> about (in what way do you need "residential customer" to apply)? >>> >> >> Very specifically, i was told that i must show specifically 80% active >> usage of all assigned addresses. >> >> I would like to move the bar from 80% demonstrated active use to 50% >> use as defined here in NRPM 4.2.3.7.3.1. >> >> The technical issues that, i assume, prompted policy in NRPM >> 4.2.3.7.3.1. applies the same way to mobile networks as it does to >> landline, thus the policy should apply the same when requesting >> resources and justifying use. >> > > In that context, I would agree... I think guidance to staff would probably > be sufficient, but failing that, a policy proposal would be needed. > > Owen > ARIN has informed me that they are not changing their interpretation of wireless not being residential service. Residential services must have wires, despite the logical architectures (CMTS = GGSN = BRAS) and commercial relationships (B2C) being highly similar. And, the fact that the majority of wireless services are consumed in the home. Wireless services (GSM, CDMA, LTE, ...) are treated like enterprise networks from ARIN policy perspective. CB >> CB >> >> >>> ~Chris >>> >>>> CB >>>> >>>> >>>>> On Jul 20, 2012, at 7:55 AM, Cameron Byrne wrote: >>>>> >>>>>> Dear PPML, >>>>>> >>>>>> Are mobile network subscribers considered residential customers? >>>>>> >>>>>> https://www.arin.net/policy/nrpm.html#two13 >>>>>> >>>>>> 2.13. Residential Customer >>>>>> >>>>>> End-users who are individual persons and not organizations and who >>>>>> receive service at a place of residence for personal use only are >>>>>> considered residential customers. >>>>>> >>>>>> I would say yes. There is no meaningful distinction from a IP >>>>>> resource utilization perspective, a cable CMTS is nearly equivalent >>>>>> to a mobile GGSN / PDSN, no? >>>>>> >>>>>> Mobile subscribers are certainly not "ISPs", they do no >>>>>> sub-delegate... or even "Enterprise Networks" ... mobile subscribers >>>>>> are 1 IP per subscription. >>>>>> >>>>>> How should ARIN staff be interpreting this term "Residential Customer" >>>>>> with regards to mobile network? Are they or are they not "residential >>>>>> customers"? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Cameron >>>>>> _______________________________________________ >>>>>> PPML >>>>>> You are receiving this message because you are subscribed to >>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>> Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> >>> >>> >>> -- >>> @ChrisGrundemann >>> http://chrisgrundemann.com >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > From info at arin.net Wed Jul 25 15:23:33 2012 From: info at arin.net (ARIN) Date: Wed, 25 Jul 2012 15:23:33 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - July 2012 Message-ID: <501047B5.5050903@arin.net> In accordance with the ARIN Policy Development Process, the ARIN Advisory Council (AC) held a meeting on 19 July 2012 and made decisions about several draft policies and proposals. The AC selected the following proposal as a draft policy for adoption discussion online and at the ARIN Public Policy Meeting in Dallas in October (ARIN XXX). The draft policy will be posted shortly to the PPML. ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers The following proposals were added to the AC's docket for development and evaluation: ARIN-prop-175 Delete Section 8.2 ARIN-prop-177 Revising Section 4.4 C/I Reserved Pool Size The AC abandoned the following proposals: ARIN-prop-166 Clarify /29 Assignment Identification Requirement ARIN-prop-173 Revisions to M&A Transfer Requirements ARIN-prop-174 Policies Apply to All Resources in the Registry ARIN-prop-176 Increase Needs-Based Justification to 60 months on 8.3 Specified Transfers ARIN-prop-178 Regional Use of Resources The AC provided the following statements about the abandoned proposals: 166. "The Advisory Council abandoned ARIN-Prop-166 because the current text is not technically sound and there has not been any significant community support for this policy change. The AC did however want to address the originator's intent and therefore the proposal's shepherd submitted the original text to ARINs suggestion process as ACSP Suggestion 2012.13 - CUSTOMER IDENTITY NOT REQUIRED ON /29 AND SMALLER REASSIGNMENTS." 173. "The ARIN Advisory Council voted to abandon ARIN-prop-173: Revisions to M&A Transfer Requirements. Consensus of the AC was that prop-173 was a political statement in the context of a larger discussion and that as such it is not necessary. Moreover, it was felt that if changes to section 8.2 of the NRPM were required there were other proposals in play that would make the tweaks in a more fine-grained manner." 174. "The ARIN Advisory Council voted to abandon ARIN-prop-174: Policies Apply to All Resources in the Registry. Consensus of the AC was that prop-174 was a political statement in the context of a larger discussion and that as such it is not necessary. Moreover, it was felt that the issue is handeled sufficiently in the RSA or LRSA contracts." 176. "The ARIN Advisory Council voted not to accept onto the docket, ARIN-prop-176 "Increase Needs-Based Justification to 60 months". The AC feels that with the change to 24 month window in 8.3 having not yet been implemented, it would be premature to increase the window of justification. As well there was concern over 60 month networking plans being speculative and difficult to evaluate." 178. "The ARIN Advisory Council voted to abandon ARIN-prop-178 "Regional Use of Resources". This proposal was brought forth in response to ARIN staff comments at the last public policy meeting regarding there being a lack of definition of where resources from a particular RIR could be used. The consensus of the AC was that this is an issue that merits further discussion and investigation but that the proposed text in prop-178 is not the solution. The AC plans to work on this issue at its next working session." The AC abandoned proposals 166, 173, 174, 176, and 178. Anyone dissatisfied with these decisions may initiate a petition. The petition to advance a proposal would be the "Discussion Petition." The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Jul 25 15:27:38 2012 From: info at arin.net (ARIN) Date: Wed, 25 Jul 2012 15:27:38 -0400 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers Message-ID: <501048AA.2090103@arin.net> Draft Policy ARIN-2012-5 Removal of Renumbering Requirement for Small Multihomers On 19 July 2012 the ARIN Advisory Council (AC) selected "Removal of Renumbering Requirement for Small Multihomers" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Dallas in October. The draft was developed by the AC from policy proposal "ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers." Per the Policy Development Process, the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment with the text that was reviewed. The text did not change after the assessment. Draft Policy ARIN-2012-5 is below and can be found at: https://www.arin.net/policy/proposals/2012_5.html You are encouraged to discuss Draft Policy 2012-5 on the PPML prior to the October Public Policy Meeting. Discussion on the list and at ARIN XXX will be used by the ARIN Advisory Council to determine community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2012-5 Removal of Renumbering Requirement for Small Multihomers Date: 25 July 2012 Policy statement: Remove the entire subsection 4.3.6.2 "Additional Assignments for Small Multihomers". Rationale: The policy has had the unintended effect of freezing small multi homed end users from being able to return to ARIN for additional assignments. The requirement to renumber out of space is unique and is applying an undue burden of renumbering what would be an organization's core infrastructure. Timetable for implementation: immediate ########## ARIN Staff and Legal Assessment ARIN STAFF ASSESSMENT ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers Date of Assessment: 16 July 2012 1. Summary (Staff Understanding) This proposal removes existing NRPM policy 4.3.6.3 "Additional Assignments for Small Multihomers". Eliminating this section removes the requirement for small multi-homers to renumber when they come back to ARIN for additional IPv4 address space. 2. Comments A. ARIN Staff Comments The original intent of NRPM 4.3.6.3 was to conserve routing table slots. However, statistics have shown that NRPM 4.3.6.3 has rarely been used and that most small multi-homers have not come back to ARIN for additional space. Therefore, it doesn't seem to be contributing anything significant toward its original goal. This policy will provide an obvious benefit to the small multi-homers who are currently being forced to suffer the pain and expense of renumbering. B. ARIN General Counsel Legal assessment: No significant legal issue is posed by this proposal. 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: Updated guidelines Staff training 4. Proposal Text ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers Date: 30 April 2012 Policy statement: Remove the entire subsection 4.3.6.2 "Additional Assignments for Small Multihomers". Rationale: The policy has had the unintended effect of freezing small multi homed end users from being able to return to ARIN for additional assignments. The requirement to renumber out of space is unique and is applying an undue burden of renumbering what would be an organization's core infrastructure. From jmaimon at chl.com Thu Jul 26 01:34:23 2012 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 26 Jul 2012 01:34:23 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 In-Reply-To: References: <50085F78.7010802@chl.com> Message-ID: <5010D6DF.1000700@chl.com> Chris Grundemann wrote: > Hi Joe, > > Perhaps if you more fully explain how this policy change would deal > with the lack of uptale of 4byte ASN (how specifically it differs from > current ARIN practice and how those changes "Promote 4byte ASN Usage") > more folks would be more in favor of it (and of your petition). I > personally have not been able to parse that myself and so it may be > possible that others are in the same boat. Just a thought. > > Cheers, > ~Chris > mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. Hey Chris, The proposal gives requesters flexibility in obtaining as numbers. This translates into preserving 16bit access for those who need or want it. It also translates into increasing attractiveness for 32bit for those who may have an affinity or preference for a specific one and under this proposal, can get it. Further, the proposal gives ARIN eyes, ears and a voice into the inner workings of why people want the numbers they do and dont want the numbers they dont. This is something ARIN does not have now. Joe From owen at delong.com Thu Jul 26 01:56:32 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 25 Jul 2012 22:56:32 -0700 Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 In-Reply-To: <5010D6DF.1000700@chl.com> References: <50085F78.7010802@chl.com> <5010D6DF.1000700@chl.com> Message-ID: <617457B4-0B61-4617-A2B9-E89FAD2D68AC@delong.com> On Jul 25, 2012, at 10:34 PM, Joe Maimon wrote: > > > Chris Grundemann wrote: >> Hi Joe, >> >> Perhaps if you more fully explain how this policy change would deal >> with the lack of uptale of 4byte ASN (how specifically it differs from >> current ARIN practice and how those changes "Promote 4byte ASN Usage") >> more folks would be more in favor of it (and of your petition). I >> personally have not been able to parse that myself and so it may be >> possible that others are in the same boat. Just a thought. >> >> Cheers, >> ~Chris >> mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > Hey Chris, > > The proposal gives requesters flexibility in obtaining as numbers. > > This translates into preserving 16bit access for those who need or want it. Current policy provides for requestors to get a 16 bit AS number until we run out of them. At that point, no amount of policy will change the fact that we are out of 16 bit AS numbers. > It also translates into increasing attractiveness for 32bit for those who may have an affinity or preference for a specific one and under this proposal, can get it. You'll need to explain how it does that. As near as I could tell, if you had a affinity for any number, 16 or 32 bit, you could request it if it was available and there was nothing specific about 32-bit ASNs in the proposal to justify the above claim. > Further, the proposal gives ARIN eyes, ears and a voice into the inner workings of why people want the numbers they do and dont want the numbers they dont. How do you figure that? It doesn't require anyone to provide that information to ARIN in the process of justifying their request. > This is something ARIN does not have now. Nor is it actually part of the proposed policy from what I read. Owen From narten at us.ibm.com Fri Jul 27 00:53:03 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 27 Jul 2012 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201207270453.q6R4r3gQ012080@rotala.raleigh.ibm.com> Total of 29 messages in the last 7 days. script run at: Fri Jul 27 00:53:03 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 24.14% | 7 | 23.81% | 56071 | cb.list6 at gmail.com 13.79% | 4 | 17.00% | 40036 | jrhett at netconsonance.com 10.34% | 3 | 10.19% | 24001 | cgrundemann at gmail.com 10.34% | 3 | 9.67% | 22768 | dogwallah at gmail.com 6.90% | 2 | 7.67% | 18057 | scottleibrand at gmail.com 6.90% | 2 | 6.81% | 16046 | info at arin.net 3.45% | 1 | 4.18% | 9835 | dave at temk.in 3.45% | 1 | 3.70% | 8705 | jcurran at arin.net 3.45% | 1 | 3.15% | 7406 | lar at mwtcorp.net 3.45% | 1 | 2.98% | 7016 | narten at us.ibm.com 3.45% | 1 | 2.98% | 7010 | owen at delong.com 3.45% | 1 | 2.80% | 6582 | heather.skanks at gmail.com 3.45% | 1 | 2.67% | 6286 | mysidia at gmail.com 3.45% | 1 | 2.39% | 5638 | jmaimon at chl.com --------+------+--------+----------+------------------------ 100.00% | 29 |100.00% | 235457 | Total From jeffmehlenbacher at ipv4marketgroup.com Fri Jul 27 07:58:09 2012 From: jeffmehlenbacher at ipv4marketgroup.com (jeffmehlenbacher at ipv4marketgroup.com) Date: Fri, 27 Jul 2012 04:58:09 -0700 Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing Justification to 60 Months Message-ID: <20120727045809.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.1592fa2e5d.wbe@email17.secureserver.net> I wonder if a representative of the AC might clarify the following statement relating to the abandonment of Prop-176: 176. "The ARIN Advisory Council voted not to accept onto the docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 months". The AC feels that with the change to 24 month window in 8.3 having not yet been implemented, it would be premature to increase the window of justification. As well there was concern over 60 month networking plans being speculative and difficult to evaluate." I actually do not understand the language above...24 months was approved and implemented on February 10th, 2012. Any clarification would be appreciated. Jeff Mehlenbacher IPv4 Market Group From kevinb at thewire.ca Fri Jul 27 09:45:55 2012 From: kevinb at thewire.ca (Kevin Blumberg) Date: Fri, 27 Jul 2012 13:45:55 +0000 Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing Justification to 60 Months In-Reply-To: <20120727045809.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.1592fa2e5d.wbe@email17.secureserver.net> References: <20120727045809.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.1592fa2e5d.wbe@email17.secureserver.net> Message-ID: <7E7773B523E82C478734E793E58F69E769619B60@SBS2011.thewireinc.local> Jeff, It was a mistake on my part. I apologize. It should of read as: 176. "The ARIN Advisory Council voted not to accept onto the docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 months". The AC feels that with the change to 24 month window in 8.3 having recently been implemented, it would be premature to increase the window of justification. As well there was concern over 60 month networking plans being speculative and difficult to evaluate." Thanks, Kevin Blumberg > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of jeffmehlenbacher at ipv4marketgroup.com > Sent: Friday, July 27, 2012 7:58 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing > Justification to 60 Months > > I wonder if a representative of the AC might clarify the following statement > relating to the abandonment of Prop-176: > > 176. "The ARIN Advisory Council voted not to accept onto the > docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 months". > The AC > feels that with the change to 24 month window in 8.3 having not yet been > implemented, it would be premature to increase the window of justification. > As well there was concern over 60 month networking plans being speculative > and difficult to evaluate." > > I actually do not understand the language above...24 months was approved > and implemented on February 10th, 2012. > > Any clarification would be appreciated. > > Jeff Mehlenbacher > IPv4 Market Group > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jmaimon at chl.com Fri Jul 27 10:08:22 2012 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 27 Jul 2012 10:08:22 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 In-Reply-To: <617457B4-0B61-4617-A2B9-E89FAD2D68AC@delong.com> References: <50085F78.7010802@chl.com> <5010D6DF.1000700@chl.com> <617457B4-0B61-4617-A2B9-E89FAD2D68AC@delong.com> Message-ID: <5012A0D6.4030805@chl.com> Owen DeLong wrote: > Current policy provides for requestors to get a 16 bit AS number until we run out of them. > > At that point, no amount of policy will change the fact that we are out of 16 bit AS numbers. No we are not. ARIN has stated that they are actually at steady state with in and out of 16bit. I want ARIN to assign 32bit by default so that 16bit supply is more assured. > > You'll need to explain how it does that. As near as I could tell, if you had a affinity for any number, 16 or 32 bit, you could request it if it was available and there was nothing specific about 32-bit ASNs in the proposal to justify the above claim. Nobody has any affinity for any number larger then 65536? > >> Further, the proposal gives ARIN eyes, ears and a voice into the inner workings of why people want the numbers they do and dont want the numbers they dont. > How do you figure that? It doesn't require anyone to provide that information to ARIN in the process of justifying their request. " 5.2.2 Requests An organization may request from ARIN either a specific AS Number or type of AS Number, if available to ARIN. The organization must document to ARIN's satisfaction technical or real world justification for its request. ARIN may review the data directly with all involved parties. " > >> This is something ARIN does not have now. > Nor is it actually part of the proposed policy from what I read. > > Owen I would hate to think that the AC abandoned a proposal without reading it. Best, Joe From jeffmehlenbacher at ipv4marketgroup.com Fri Jul 27 10:12:22 2012 From: jeffmehlenbacher at ipv4marketgroup.com (jeffmehlenbacher at ipv4marketgroup.com) Date: Fri, 27 Jul 2012 07:12:22 -0700 Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing Justification to 60 Months Message-ID: <20120727071222.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.25d4f0f5ad.wbe@email17.secureserver.net> Thank you Kevin. It will then be interesting to understand what metrics are being applied and monitored to determine whether 24 months is an appropriate duration for justification. The onus for change should not be on external parties, but rather, ARIN staff should produce statistics that support the AC's assertion that 24 months is appropriate. Jeff Mehlenbacher -------- Original Message -------- Subject: RE: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing Justification to 60 Months From: Kevin Blumberg Date: Fri, July 27, 2012 9:45 am To: "jeffmehlenbacher at ipv4marketgroup.com" , "arin-ppml at arin.net" Jeff, It was a mistake on my part. I apologize. It should of read as: 176. "The ARIN Advisory Council voted not to accept onto the docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 months". The AC feels that with the change to 24 month window in 8.3 having recently been implemented, it would be premature to increase the window of justification. As well there was concern over 60 month networking plans being speculative and difficult to evaluate." Thanks, Kevin Blumberg > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of jeffmehlenbacher at ipv4marketgroup.com > Sent: Friday, July 27, 2012 7:58 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing > Justification to 60 Months > > I wonder if a representative of the AC might clarify the following statement > relating to the abandonment of Prop-176: > > 176. "The ARIN Advisory Council voted not to accept onto the > docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 months". > The AC > feels that with the change to 24 month window in 8.3 having not yet been > implemented, it would be premature to increase the window of justification. > As well there was concern over 60 month networking plans being speculative > and difficult to evaluate." > > I actually do not understand the language above...24 months was approved > and implemented on February 10th, 2012. > > Any clarification would be appreciated. > > Jeff Mehlenbacher > IPv4 Market Group > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From scottleibrand at gmail.com Fri Jul 27 10:22:04 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 27 Jul 2012 10:22:04 -0400 Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing Justification to 60 Months In-Reply-To: <20120727071222.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.25d4f0f5ad.wbe@email17.secureserver.net> References: <20120727071222.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.25d4f0f5ad.wbe@email17.secureserver.net> Message-ID: Jeff, While the majority of the AC disagreed with my opinion that it would be best to have this proposal on the docket for discussion in October, everyone did seem to agree that this was an important issue to discuss. ARIN does report on registration and transfer activity at each meeting: I will be particularly interested to see how inter-RIR transfers play out over the first few months they're available. If/when you have any insight there, I'd like to hear it as well. -Scott On Fri, Jul 27, 2012 at 10:12 AM, wrote: > Thank you Kevin. It will then be interesting to understand what metrics > are being applied and monitored to determine whether 24 months is an > appropriate duration for justification. The onus for change should not > be on external parties, but rather, ARIN staff should produce statistics > that support the AC's assertion that 24 months is appropriate. > > Jeff Mehlenbacher > > -------- Original Message -------- > Subject: RE: [arin-ppml] Clarification on AC Abandonment of Prop-176: > Increasing Justification to 60 Months > From: Kevin Blumberg > Date: Fri, July 27, 2012 9:45 am > To: "jeffmehlenbacher at ipv4marketgroup.com" > , "arin-ppml at arin.net" > > > Jeff, > > It was a mistake on my part. I apologize. It should of read as: > > 176. "The ARIN Advisory Council voted not to accept onto the > docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 months". > The AC feels that with the change to 24 month window in 8.3 having > recently > been implemented, it would be premature to increase the window of > justification. > As well there was concern over 60 month networking plans being > speculative > and difficult to evaluate." > > Thanks, > > Kevin Blumberg > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > > Behalf Of jeffmehlenbacher at ipv4marketgroup.com > > Sent: Friday, July 27, 2012 7:58 AM > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: > Increasing > > Justification to 60 Months > > > > I wonder if a representative of the AC might clarify the following > statement > > relating to the abandonment of Prop-176: > > > > 176. "The ARIN Advisory Council voted not to accept onto the > > docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 months". > > The AC > > feels that with the change to 24 month window in 8.3 having not yet been > > implemented, it would be premature to increase the window of > justification. > > As well there was concern over 60 month networking plans being > speculative > > and difficult to evaluate." > > > > I actually do not understand the language above...24 months was approved > > and implemented on February 10th, 2012. > > > > Any clarification would be appreciated. > > > > Jeff Mehlenbacher > > IPv4 Market Group > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Jul 27 13:50:50 2012 From: farmer at umn.edu (David Farmer) Date: Fri, 27 Jul 2012 12:50:50 -0500 Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing Justification to 60 Months In-Reply-To: References: <20120727071222.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.25d4f0f5ad.wbe@email17.secureserver.net> Message-ID: <5012D4FA.3000900@umn.edu> I'm also very interested in there being a discussion of this issue. However, I voted to abandon this proposal mostly to try to clam things down a bit, wanting to focus the discussion on what the proper next steps are and what the time table should be. Rather than arguing about the merits of this specific proposal especially its 60 month window which I'm highly skeptical of being able to achieve consensus. There are a number of moving pieces here, 24 months only went into effect in February, Inter-RIR transfers should go into effect in the next week or so. While I generally support moving beyond 24 months, I would prefer to be cautious about when to do it. I supported 24 months last fall because while longer than ARIN had normally done, it is not without precedent in the RIR policy space, and it was clear to me that we needed a longer window than 12 months. I'm not aware on any RIR ever having a longer window than 24 months, so 24 months immediately and longer over time seemed like a reasonable but cautious path forward.. On the other I'm not saying that 60 months is complete out of the questions either, there are valid business reasons for that number too. I fully support a 60 month planing horizon for IPv6, I'm just not convinced that 60 months is reasonable for IPv4 at this point in its life cycle. I would like to suggest the proper focus for ARIN policy is not the success or failure of the IPv4 transfer market place, but the success or failure or the Internet market place. I personally believe that they are not mutually exclusive, they are interdependent, but the short and long term health of the Internet market place is way more important than the IPv4 transfer market place, not the other way around. Thanks On 7/27/12 09:22 CDT, Scott Leibrand wrote: > Jeff, > > While the majority of the AC disagreed with my opinion that it would be > best to have this proposal on the docket for discussion in October, > everyone did seem to agree that this was an important issue to discuss. > ARIN does report on registration and transfer activity at each > meeting: I will be particularly interested to see how inter-RIR > transfers play out over the first few months they're available. If/when > you have any insight there, I'd like to hear it as well. > > -Scott > > On Fri, Jul 27, 2012 at 10:12 AM, > wrote: > > Thank you Kevin. It will then be interesting to understand what metrics > are being applied and monitored to determine whether 24 months is an > appropriate duration for justification. The onus for change should not > be on external parties, but rather, ARIN staff should produce statistics > that support the AC's assertion that 24 months is appropriate. > > Jeff Mehlenbacher > > -------- Original Message -------- > Subject: RE: [arin-ppml] Clarification on AC Abandonment of Prop-176: > Increasing Justification to 60 Months > From: Kevin Blumberg > > Date: Fri, July 27, 2012 9:45 am > To: "jeffmehlenbacher at ipv4marketgroup.com > " > >, "arin-ppml at arin.net > " > > > > Jeff, > > It was a mistake on my part. I apologize. It should of read as: > > 176. "The ARIN Advisory Council voted not to accept onto the > docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 months". > The AC feels that with the change to 24 month window in 8.3 having > recently > been implemented, it would be premature to increase the window of > justification. > As well there was concern over 60 month networking plans being > speculative > and difficult to evaluate." > > Thanks, > > Kevin Blumberg > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net > ] On > > Behalf Of jeffmehlenbacher at ipv4marketgroup.com > > > Sent: Friday, July 27, 2012 7:58 AM > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: > Increasing > > Justification to 60 Months > > > > I wonder if a representative of the AC might clarify the > following statement > > relating to the abandonment of Prop-176: > > > > 176. "The ARIN Advisory Council voted not to accept onto the > > docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 > months". > > The AC > > feels that with the change to 24 month window in 8.3 having not > yet been > > implemented, it would be premature to increase the window of > justification. > > As well there was concern over 60 month networking plans being > speculative > > and difficult to evaluate." > > > > I actually do not understand the language above...24 months was > approved > > and implemented on February 10th, 2012. > > > > Any clarification would be appreciated. > > > > Jeff Mehlenbacher > > IPv4 Market Group > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net > ). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you > experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at telnetcommunications.com Fri Jul 27 14:51:25 2012 From: bill at telnetcommunications.com (Bill Sandiford) Date: Fri, 27 Jul 2012 14:51:25 -0400 Subject: [arin-ppml] New Policy Proposal Message-ID: TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: Reassignments for Third Party Internet Access (TPIA) over Cable 2. Proposal Originator a. name: Bill Sandiford b. email: bill at sandiford.com c. telephone: 905-409-5228 d. organization: Telnet Communications 3. Proposal Version: 1 4. Date: July 27, 2012 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Insert new section to NRPM to read as follows: 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable When IP address resources are reassigned by an ISP to an underlying cable carrier for use with TPIA, those addresses shall be deemed as utilized once they are assigned to equipment by the underlying cable carrier. 8. Rationale: A unique situation exists particularly, and perhaps only, in the Canadian region that is preventing legitimate ISPs from obtaining subsequent allocations of IPv4 addresses for use with the Third Party Internet Access (TPIA) framework that has been mandated by the CRTC (Canada's version of the FCC). Adding this section to the NRPM will allow ISPs that intend to make use of this CRTC mandated framework to obtain the number resources that they require but are currently unable to obtain. 9. Timetable for implementation: immediate END OF TEMPLATE From rocca at start.ca Fri Jul 27 15:04:31 2012 From: rocca at start.ca (Peter Rocca) Date: Fri, 27 Jul 2012 15:04:31 -0400 Subject: [arin-ppml] New Policy Proposal In-Reply-To: References: Message-ID: I support this policy proposal as written. On 2012-07-27 2:51 PM, "Bill Sandiford" wrote: >TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > >1. Policy Proposal Name: Reassignments for Third Party Internet Access >(TPIA) over Cable >2. Proposal Originator > a. name: Bill Sandiford > b. email: bill at sandiford.com > c. telephone: 905-409-5228 > d. organization: Telnet Communications > >3. Proposal Version: 1 >4. Date: July 27, 2012 >5. Proposal type: new >6. Policy term: permanent >7. Policy statement: >Insert new section to NRPM to read as follows: > >4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable > >When IP address resources are reassigned by an ISP to an underlying >cable carrier for use with TPIA, those addresses shall be deemed as >utilized once they are assigned to equipment by the underlying cable carrier. > >8. Rationale: >A unique situation exists particularly, and perhaps only, in the >Canadian region that is preventing legitimate ISPs from obtaining >subsequent allocations of IPv4 addresses for use with the Third Party >Internet Access >(TPIA) framework that has been mandated by the CRTC (Canada's version >of the FCC). Adding this section to the NRPM will allow ISPs that >intend to make use of this CRTC mandated framework to obtain the number >resources that they require but are currently unable to obtain. >9. Timetable for implementation: immediate > >END OF TEMPLATE From info at arin.net Fri Jul 27 15:05:34 2012 From: info at arin.net (ARIN) Date: Fri, 27 Jul 2012 15:05:34 -0400 Subject: [arin-ppml] ARIN-prop-179 Reassignments for Third Party Internet Access (TPIA) over Cable (was: Re: New Policy Proposal) Message-ID: <5012E67E.7030903@arin.net> ARIN-prop-179 Reassignments for Third Party Internet Access (TPIA) over Cable ARIN received the following policy proposal. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at:https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-179 Reassignments for Third Party Internet Access (TPIA) over Cable On 7/27/12 2:51 PM, Bill Sandiford wrote: > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: Reassignments for Third Party Internet Access > (TPIA) over Cable > 2. Proposal Originator > a. name: Bill Sandiford > b. email: bill at sandiford.com > c. telephone: 905-409-5228 > d. organization: Telnet Communications > > 3. Proposal Version: 1 > 4. Date: July 27, 2012 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > Insert new section to NRPM to read as follows: > > 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable > > When IP address resources are reassigned by an ISP to an underlying cable > carrier for use with TPIA, those addresses shall be deemed as utilized > once they are assigned to equipment by the underlying cable carrier. > > 8. Rationale: > A unique situation exists particularly, and perhaps only, in the Canadian > region that is preventing legitimate ISPs from obtaining subsequent > allocations of IPv4 addresses for use with the Third Party Internet Access > (TPIA) framework that has been mandated by the CRTC (Canada's version of > the FCC). Adding this section to the NRPM will allow ISPs that intend to > make use of this CRTC mandated framework to obtain the number resources > that they require but are currently unable to obtain. > 9. Timetable for implementation: immediate > > END OF TEMPLATE > From info at arin.net Fri Jul 27 15:12:10 2012 From: info at arin.net (ARIN) Date: Fri, 27 Jul 2012 15:12:10 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 In-Reply-To: <50088148.1040003@arin.net> References: <50088148.1040003@arin.net> Message-ID: <5012E80A.4050109@arin.net> This petition did not receive the required 10 statements of support and was therefore not successful. ARIN-prop-168 is closed. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 7/19/12 5:51 PM, ARIN wrote: > ARIN-prop-168 Promote 4byte ASN Usage > > The message below started a petition regarding the ARIN Advisory > Council's decision to abandon ARIN-prop-168. The AC's decision was > posted by ARIN staff to PPML on 26 June 2012. > > If successful, this petition will change ARIN-prop-168 into a Draft > Policy which will be published for adoption discussion on the PPML and > at the Public Policy Meeting in October 2012. If the petition fails, > the proposal will be closed. > > For this petition to be successful, the petition needs statements of > support from at least 10 different people from 10 different > organizations. If you wish to support this petition, post a statement > of support to PPML on this thread. > > The duration of the petition is five business days; it ends on 26 July > 2012. ARIN staff will post the result of the petition to PPML. > > For more information on starting and participating in petitions, see > PDP Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > The proposal text is below and at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ##### > > >> -----Original Message----- >> From: Joe Maimon >> Date: Thu, 19 Jul 2012 15:26:48 -0400 >> To: "ppml >> \"ppml at arin.net\"" >> Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 >> >> All, >> >> Policy Proposal #168 Promote 4byte ASN Usage, was intended to deal with >> the lack of uptake of 4byte ASN as well as the continued demand for >> 2byte ASN. >> >> It does so by expanding on the capabilities of both the community and >> ARIN with regards to ASN policy. >> >> I believe that more discussion on this topic is warranted. ARIN Staff >> said as much at previous PPM and I was hoping that this proposal would >> help do that. >> >> As such, the AC's abandonment of this proposal was disappointing to me. >> >> While it may not be as compelling and controversial as some of the >> topics swirling through the list these days, ASN policy is important, >> disproportionately so, to the newcomers of our community. >> >> I formally petition you, the members of this community, for your support >> in advancing to draft policy status the proposal and for it to be >> discussed at an upcoming ARIN Public Policy meeting. >> >> I ask you for statements in support of this petition. >> >> The full policy proposal text is available at >> >> http://lists.arin.net/pipermail/arin-ppml/2012-May/024892.html >> >> Best and my thanks, >> >> Joe >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > ARIN-prop-168 Promote 4byte ASN Usage > > Proposal Originator: Joe Maimon > > Proposal Version: 1.1 > > Date: 18 May 2012 > > Proposal type: Modify > > Policy term: Temporary > > Policy statement: > > Add section 5.2 > > 5.2 Guidelines > > ARIN will issue AS Numbers under the following guidelines. > > 5.2.1 Unused > > ARIN will attempt to assign to the organization an AS Number which has > neither been previously assigned nor publicly used, as available. > > 5.2.2 Requests > > An organization may request from ARIN either a specific AS Number or > type of AS Number, if available to ARIN. The organization must document > to ARIN's satisfaction technical or real world justification for its > request. ARIN may review the data directly with all involved parties. > > 5.2.3 Rectification > > ARIN may reuse the provided documentation in such public and private > forums as it deems appropriate and useful to promote the rectification > of issues documented via 5.2.2 request justification. > > 5.2.4 Restrictions > > Assignments received via 5.2.2 requests are additionally restricted from > 8.3 transfers for a period of 24 months post assignment. > > 5.2.5 Release > > An organization can exchange the 5.2.2 number for a 5.2.1 number, after > which time the restriction on transferring the assignment will be > released. > > 5.2.6 Publication > > Section 5.2 neither requires nor recommends that ARIN publicize its > available AS Numbers. > > 5.2.7 Expiration > > ARIN may retire section 5.2 anytime during a period of more than 24 > calendar months that have gone by without any completed 5.2.2 requests. > > > Rationale: > > Changes from V1.0 > > 5.2.1 "used" -> "publicly used" > > 5.2.2 "must provide" -> "must document" > > 5.2.2 "technical justification " -> "technical or real world > justification" > > 5.2.3 strike "with suitable privacy considerations in place" > > 5.2.3 "public forums" -> "public or private forums" > > 5.2.3 "necessary to promote" -> "appropriate and useful to promote" > > 5.2.3 "rectification of documented causes" -> "rectification of issues > documented via 5.2.2 request justification" > > 5.2.4 "being transferred" -> "from 8.3 transfers" > > 5.2.7 "after a period of" -> "during a period of more than" > > Unless otherwise requested, providing an ASN with no baggage or history > should be preferential to both the organization and to ARIN. > > The restrictions and clauses regarding technical justification are > designed for the promotion of 4byte ASN uptake and preservation of 2byte > ASN's for those who truly need them. Additionally, this may help to > assist in resolving apparently pervasive obstacles in the ARIN region to > using 4byte ASN's. > > Further, if an organization does have a valid technical justification > for a specific AS Number that is available, for example, when a network > was built with an ASN that was subsequently reclaimed due to accidental > negligence or other similar cases, there is little benefit to ARIN > refusing to provide the organization what it can show it needs. > > ARIN need not publicize available ASNs but it may choose to do so if it > is the most efficient and prudent method of implementation. > > Should this policy become a relic (we hope), ARIN is expressly > authorized to excise it. > > Timetable for implementation: Immediate. > > > From scottleibrand at gmail.com Fri Jul 27 15:45:30 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 27 Jul 2012 15:45:30 -0400 Subject: [arin-ppml] New Policy Proposal In-Reply-To: References: Message-ID: Can you explain the process of how IP addresses are assigned, reassigned, and used for TPIA? I think I have an idea of how it works based on your policy text, but I'd like confirmation on that. Thanks, Scott On Fri, Jul 27, 2012 at 2:51 PM, Bill Sandiford < bill at telnetcommunications.com> wrote: > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: Reassignments for Third Party Internet Access > (TPIA) over Cable > 2. Proposal Originator > a. name: Bill Sandiford > b. email: bill at sandiford.com > c. telephone: 905-409-5228 > d. organization: Telnet Communications > > 3. Proposal Version: 1 > 4. Date: July 27, 2012 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > Insert new section to NRPM to read as follows: > > 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable > > When IP address resources are reassigned by an ISP to an underlying cable > carrier for use with TPIA, those addresses shall be deemed as utilized > once they are assigned to equipment by the underlying cable carrier. > > 8. Rationale: > A unique situation exists particularly, and perhaps only, in the Canadian > region that is preventing legitimate ISPs from obtaining subsequent > allocations of IPv4 addresses for use with the Third Party Internet Access > (TPIA) framework that has been mandated by the CRTC (Canada's version of > the FCC). Adding this section to the NRPM will allow ISPs that intend to > make use of this CRTC mandated framework to obtain the number resources > that they require but are currently unable to obtain. > 9. Timetable for implementation: immediate > > END OF TEMPLATE > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkargel at polartel.com Fri Jul 27 15:58:44 2012 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 27 Jul 2012 14:58:44 -0500 Subject: [arin-ppml] New Policy Proposal In-Reply-To: References: Message-ID: <8695009A81378E48879980039EEDAD280122CB0760@MAIL1.polartel.local> Isn't this already covered somehow? As an ISP if I SWIP IP addresses to a peer or a customer I understand that those addresses may require utilization substantiation. What makes the Canadian ISP's different from the rest of us so that they should not be required to provide utilization data from their customers? Are the Canadian ISP's required by government mandate to allocate IP's to cable providers in some mandated quantity without any requirement for the cable operators to provide need or utilization documentation? How do you determine how big of a block to assign them? If this is to go through I believe it should be written to apply to all ISP's equally without reference to local regulation such as TPIA, perhaps to just accept SWIPs as utilized without documentation. I do not believe I would support that. It would radically change my future planning. If I understand the problem better my position may change. Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Bill Sandiford > Sent: Friday, July 27, 2012 1:51 PM > To: policy at arin.net > Cc: arin-ppml at arin.net > Subject: [arin-ppml] New Policy Proposal > > TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: Reassignments for Third Party Internet Access > (TPIA) over Cable > 2. Proposal Originator > a. name: Bill Sandiford > b. email: bill at sandiford.com > c. telephone: 905-409-5228 > d. organization: Telnet Communications > > 3. Proposal Version: 1 > 4. Date: July 27, 2012 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > Insert new section to NRPM to read as follows: > > 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable > > When IP address resources are reassigned by an ISP to an underlying cable > carrier for use with TPIA, those addresses shall be deemed as utilized > once they are assigned to equipment by the underlying cable carrier. > > 8. Rationale: > A unique situation exists particularly, and perhaps only, in the Canadian > region that is preventing legitimate ISPs from obtaining subsequent > allocations of IPv4 addresses for use with the Third Party Internet Access > (TPIA) framework that has been mandated by the CRTC (Canada's version of > the FCC). Adding this section to the NRPM will allow ISPs that intend to > make use of this CRTC mandated framework to obtain the number resources > that they require but are currently unable to obtain. > 9. Timetable for implementation: immediate > > END OF TEMPLATE > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4935 bytes Desc: not available URL: From kevinb at thewire.ca Fri Jul 27 16:00:12 2012 From: kevinb at thewire.ca (Kevin Blumberg) Date: Fri, 27 Jul 2012 20:00:12 +0000 Subject: [arin-ppml] New Policy Proposal In-Reply-To: References: , Message-ID: <7E7773B523E82C478734E793E58F69E76961A559@SBS2011.thewireinc.local> Kevin Blumberg The Wire Inc. 416.214.9473x31 www.thewire.ca -----Original Message----- From: Scott Leibrand [scottleibrand at gmail.com] Received: Friday, 27 Jul 2012, 3:45pm To: Bill Sandiford [bill at telnetcommunications.com] CC: arin-ppml at arin.net [arin-ppml at arin.net] Subject: Re: [arin-ppml] New Policy Proposal Can you explain the process of how IP addresses are assigned, reassigned, and used for TPIA? I think I have an idea of how it works based on your policy text, but I'd like confirmation on that. Thanks, Scott On Fri, Jul 27, 2012 at 2:51 PM, Bill Sandiford > wrote: TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: Reassignments for Third Party Internet Access (TPIA) over Cable 2. Proposal Originator a. name: Bill Sandiford b. email: bill at sandiford.com c. telephone: 905-409-5228 d. organization: Telnet Communications 3. Proposal Version: 1 4. Date: July 27, 2012 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Insert new section to NRPM to read as follows: 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable When IP address resources are reassigned by an ISP to an underlying cable carrier for use with TPIA, those addresses shall be deemed as utilized once they are assigned to equipment by the underlying cable carrier. 8. Rationale: A unique situation exists particularly, and perhaps only, in the Canadian region that is preventing legitimate ISPs from obtaining subsequent allocations of IPv4 addresses for use with the Third Party Internet Access (TPIA) framework that has been mandated by the CRTC (Canada's version of the FCC). Adding this section to the NRPM will allow ISPs that intend to make use of this CRTC mandated framework to obtain the number resources that they require but are currently unable to obtain. 9. Timetable for implementation: immediate END OF TEMPLATE _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rocca at start.ca Fri Jul 27 16:00:52 2012 From: rocca at start.ca (Peter Rocca) Date: Fri, 27 Jul 2012 16:00:52 -0400 Subject: [arin-ppml] New Policy Proposal In-Reply-To: References: Message-ID: The high-level overview is that the allocation is routed to the TPIA provider who then carves it up into smaller blocks and routes them to different 'serving areas' which are geographical groupings of CMTS's. Those serving areas then have smaller DHCP pools (generally /27's or /28's) assigned at the node level. End-users are assigned IP's from the DHCP of the node they are served by. Once the space is provided to the TPIA provider the ISP no longer has control over the routing, renumbering or specific assignments within the TPIA network. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: July-27-12 3:46 PM To: Bill Sandiford Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] New Policy Proposal Can you explain the process of how IP addresses are assigned, reassigned, and used for TPIA? I think I have an idea of how it works based on your policy text, but I'd like confirmation on that. Thanks, Scott On Fri, Jul 27, 2012 at 2:51 PM, Bill Sandiford > wrote: TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: Reassignments for Third Party Internet Access (TPIA) over Cable 2. Proposal Originator a. name: Bill Sandiford b. email: bill at sandiford.com c. telephone: 905-409-5228 d. organization: Telnet Communications 3. Proposal Version: 1 4. Date: July 27, 2012 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: Insert new section to NRPM to read as follows: 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable When IP address resources are reassigned by an ISP to an underlying cable carrier for use with TPIA, those addresses shall be deemed as utilized once they are assigned to equipment by the underlying cable carrier. 8. Rationale: A unique situation exists particularly, and perhaps only, in the Canadian region that is preventing legitimate ISPs from obtaining subsequent allocations of IPv4 addresses for use with the Third Party Internet Access (TPIA) framework that has been mandated by the CRTC (Canada's version of the FCC). Adding this section to the NRPM will allow ISPs that intend to make use of this CRTC mandated framework to obtain the number resources that they require but are currently unable to obtain. 9. Timetable for implementation: immediate END OF TEMPLATE _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Jul 27 16:00:48 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Jul 2012 13:00:48 -0700 Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 In-Reply-To: <5012A0D6.4030805@chl.com> References: <50085F78.7010802@chl.com> <5010D6DF.1000700@chl.com> <617457B4-0B61-4617-A2B9-E89FAD2D68AC@delong.com> <5012A0D6.4030805@chl.com> Message-ID: <92695E7A-0DEC-4AD5-9E36-D1BC584EC354@delong.com> On Jul 27, 2012, at 7:08 AM, Joe Maimon wrote: > > > Owen DeLong wrote: >> Current policy provides for requestors to get a 16 bit AS number until we run out of them. >> >> At that point, no amount of policy will change the fact that we are out of 16 bit AS numbers. > > No we are not. ARIN has stated that they are actually at steady state with in and out of 16bit. > I don't recall them saying that, but, if that is the case, we will have 16 bit AS numbers for as long that remains the case and there is no problem. > I want ARIN to assign 32bit by default so that 16bit supply is more assured. Your policy proposal doesn't actually do that. Instead, it provides for people to ask for vanity ASNs in the full number space. >> You'll need to explain how it does that. As near as I could tell, if you had a affinity for any number, 16 or 32 bit, you could request it if it was available and there was nothing specific about 32-bit ASNs in the proposal to justify the above claim. > > Nobody has any affinity for any number larger then 65536? I don't know. I bet more people have affinities for numbers <65,536 than >65,536, however, so if that is your best argument for how this policy would encourage 32-bit adoption, I have to say I think it would have the opposite effect. >>> Further, the proposal gives ARIN eyes, ears and a voice into the inner workings of why people want the numbers they do and dont want the numbers they dont. >> How do you figure that? It doesn't require anyone to provide that information to ARIN in the process of justifying their request. > > " > > 5.2.2 Requests > > An organization may request from ARIN either a specific AS Number or > type of AS Number, if available to ARIN. The organization must document > to ARIN's satisfaction technical or real world justification for its > request. ARIN may review the data directly with all involved parties. > " I (and I suspect ARIN staff) would interpret that to mean justifying the ASN, not the reason one was seeking the specific ASN or specific type of ASN. Further, since you're allowing, essentially, vanity ASNs, I suspect a lot of the real-world reasons for wanting a particular ASN would be "we like it and it's what we want" or something roughly equivalent even if ARIN were to interpret the above language in that context. >>> This is something ARIN does not have now. >> Nor is it actually part of the proposed policy from what I read. >> >> Owen > > I would hate to think that the AC abandoned a proposal without reading it. Rest assured, I read it thoroughly and completely and did so more than once. As I stated above, I do not believe that it says or does what you appear to think it will do. Owen From rocca at start.ca Fri Jul 27 16:13:55 2012 From: rocca at start.ca (Peter Rocca) Date: Fri, 27 Jul 2012 16:13:55 -0400 Subject: [arin-ppml] New Policy Proposal In-Reply-To: <8695009A81378E48879980039EEDAD280122CB0760@MAIL1.polartel.local> References: <8695009A81378E48879980039EEDAD280122CB0760@MAIL1.polartel.local> Message-ID: > Isn't this already covered somehow? As an ISP if I SWIP IP addresses to a peer or a customer > I understand that those addresses may require utilization substantiation. ARIN does not currently accept the SWIP as utilized as the TPIA provider by definition is not a 'customer' of the ISP. > Are the Canadian ISP's required by government mandate to allocate IP's to cable providers in some > mandated quantity without any requirement for the cable operators to provide need or utilization > documentation? How do you determine how big of a block to assign them? The problem being faced is the inability to receive subsequent allocations. Specifically, once the initial allocation is used to number the footprint of the network (using small subnets to each node) it is impossible to achieve a 50% utilization of that initial allocation before any single node exhausts its pool. This policy would enable a subsequent allocation which would then be able to target areas of growth and augment the specific nodes that had become exhausted. This would greatly increase the overall utilization efficiency of the initial allocation which as a result would be able to reach the 50% threshold and qualify for future requests through existing policy. From owen at delong.com Fri Jul 27 16:21:57 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 27 Jul 2012 13:21:57 -0700 Subject: [arin-ppml] ARIN-prop-179 Reassignments for Third Party Internet Access (TPIA) over Cable (was: Re: New Policy Proposal) In-Reply-To: <5012E67E.7030903@arin.net> References: <5012E67E.7030903@arin.net> Message-ID: I'm OK with the intent of this policy. I'd like to see it expressed in more generic terms and have a definition for those terms added to section 2 so that it could apply to competitive access scenarios anywhere in the region rather than being defined in terms of the current situation in Canada. Owen On Jul 27, 2012, at 12:05 PM, ARIN wrote: > ARIN-prop-179 Reassignments for Third Party Internet Access > (TPIA) over Cable > > ARIN received the following policy proposal. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at:https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-179 Reassignments for Third Party Internet Access > (TPIA) over Cable > > On 7/27/12 2:51 PM, Bill Sandiford wrote: > >> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 >> >> 1. Policy Proposal Name: Reassignments for Third Party Internet Access >> (TPIA) over Cable >> 2. Proposal Originator >> a. name: Bill Sandiford >> b. email: bill at sandiford.com >> c. telephone: 905-409-5228 >> d. organization: Telnet Communications >> >> 3. Proposal Version: 1 >> 4. Date: July 27, 2012 >> 5. Proposal type: new >> 6. Policy term: permanent >> 7. Policy statement: >> Insert new section to NRPM to read as follows: >> >> 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable >> >> When IP address resources are reassigned by an ISP to an underlying cable >> carrier for use with TPIA, those addresses shall be deemed as utilized >> once they are assigned to equipment by the underlying cable carrier. >> >> 8. Rationale: >> A unique situation exists particularly, and perhaps only, in the Canadian >> region that is preventing legitimate ISPs from obtaining subsequent >> allocations of IPv4 addresses for use with the Third Party Internet Access >> (TPIA) framework that has been mandated by the CRTC (Canada's version of >> the FCC). Adding this section to the NRPM will allow ISPs that intend to >> make use of this CRTC mandated framework to obtain the number resources >> that they require but are currently unable to obtain. >> 9. Timetable for implementation: immediate >> >> END OF TEMPLATE >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at telnetcommunications.com Fri Jul 27 16:30:08 2012 From: bill at telnetcommunications.com (Bill Sandiford) Date: Fri, 27 Jul 2012 16:30:08 -0400 Subject: [arin-ppml] ARIN-prop-179 Reassignments for Third Party Internet Access (TPIA) over Cable (was: Re: New Policy Proposal) In-Reply-To: Message-ID: Great points Owen. Happy to work to accomplish what you suggest. On 2012-07-27 4:21 PM, "Owen DeLong" wrote: >I'm OK with the intent of this policy. > >I'd like to see it expressed in more generic terms and have a definition >for those terms added to section 2 so that it could apply to competitive >access scenarios anywhere in the region rather than being defined in >terms of the current situation in Canada. > >Owen > >On Jul 27, 2012, at 12:05 PM, ARIN wrote: > >> ARIN-prop-179 Reassignments for Third Party Internet Access >> (TPIA) over Cable >> >> ARIN received the following policy proposal. >> >> The ARIN Advisory Council (AC) will review the proposal at their next >> regularly scheduled meeting (if the period before the next regularly >> scheduled meeting is less than 10 days, then the period may be extended >> to the subsequent regularly scheduled meeting). The AC will decide how >> to utilize the proposal and announce the decision to the PPML. >> >> The AC invites everyone to comment on the proposal on the PPML, >> particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their >>deliberations. >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Mailing list subscription information can be found >> at:https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> ARIN-prop-179 Reassignments for Third Party Internet Access >> (TPIA) over Cable >> >> On 7/27/12 2:51 PM, Bill Sandiford wrote: >> >>> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 >>> >>> 1. Policy Proposal Name: Reassignments for Third Party Internet Access >>> (TPIA) over Cable >>> 2. Proposal Originator >>> a. name: Bill Sandiford >>> b. email: bill at sandiford.com >>> c. telephone: 905-409-5228 >>> d. organization: Telnet Communications >>> >>> 3. Proposal Version: 1 >>> 4. Date: July 27, 2012 >>> 5. Proposal type: new >>> 6. Policy term: permanent >>> 7. Policy statement: >>> Insert new section to NRPM to read as follows: >>> >>> 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable >>> >>> When IP address resources are reassigned by an ISP to an underlying >>>cable >>> carrier for use with TPIA, those addresses shall be deemed as utilized >>> once they are assigned to equipment by the underlying cable carrier. >>> >>> 8. Rationale: >>> A unique situation exists particularly, and perhaps only, in the >>>Canadian >>> region that is preventing legitimate ISPs from obtaining subsequent >>> allocations of IPv4 addresses for use with the Third Party Internet >>>Access >>> (TPIA) framework that has been mandated by the CRTC (Canada's version >>>of >>> the FCC). Adding this section to the NRPM will allow ISPs that intend >>>to >>> make use of this CRTC mandated framework to obtain the number resources >>> that they require but are currently unable to obtain. >>> 9. Timetable for implementation: immediate >>> >>> END OF TEMPLATE >>> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. From jmaimon at chl.com Fri Jul 27 16:58:04 2012 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 27 Jul 2012 16:58:04 -0400 Subject: [arin-ppml] Petition for advancement of Policy Proposal #168 In-Reply-To: <92695E7A-0DEC-4AD5-9E36-D1BC584EC354@delong.com> References: <50085F78.7010802@chl.com> <5010D6DF.1000700@chl.com> <617457B4-0B61-4617-A2B9-E89FAD2D68AC@delong.com> <5012A0D6.4030805@chl.com> <92695E7A-0DEC-4AD5-9E36-D1BC584EC354@delong.com> Message-ID: <501300DC.1070709@chl.com> Owen DeLong wrote: > On Jul 27, 2012, at 7:08 AM, Joe Maimon wrote: > > I don't know. I bet more people have affinities for numbers<65,536 than>65,536, however, so if that is your best argument for how this policy would encourage 32-bit adoption, I have to say I think it would have the opposite effect. Since the number of 32bit ASN use in the ARIN region is statistical noise, there is only one direction to go. > I (and I suspect ARIN staff) would interpret that to mean justifying > the ASN, not the reason one was seeking the specific ASN or specific > type of ASN. Further, since you're allowing, essentially, vanity ASNs, > I suspect a lot of the real-world reasons for wanting a particular ASN > would be "we like it and it's what we want" or something roughly > equivalent even if ARIN were to interpret the above language in that > context. That is most definitely not the intent of the words I wrote. And if ARIN wants further guidance on what is satisfactory, at least they will have something to talk to us about, instead of a bunch of blank guesses. > As I stated above, I do not believe that it says or does what you > appear to think it will do. Owen Fair enough. Short lived as this proposal was, I am optimistic that its contribution to our dialogue was positive and constructive. Thank you to all who participated and donated of their cycles to this proposals. Best, Joe From lsawyer at gci.com Fri Jul 27 16:58:49 2012 From: lsawyer at gci.com (Leif Sawyer) Date: Fri, 27 Jul 2012 12:58:49 -0800 Subject: [arin-ppml] ARIN-prop-179 Reassignments for Third Party Internet Access (TPIA) over Cable (was: Re: New Policy Proposal) In-Reply-To: References: Message-ID: <18B2C6E38A3A324986B392B2D18ABC5101EB772B0C@fnb1mbx01.gci.com> I do support the policy as written, however would prefer to see the changes as suggested by Owen moved forward. > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Sandiford > Sent: Friday, July 27, 2012 12:30 PM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-179 Reassignments for > Third Party Internet Access (TPIA) over Cable (was: Re: New > Policy Proposal) > > Great points Owen. > > > Happy to work to accomplish what you suggest. > > > On 2012-07-27 4:21 PM, "Owen DeLong" wrote: > > >I'm OK with the intent of this policy. > > > >I'd like to see it expressed in more generic terms and have > a definition > >for those terms added to section 2 so that it could apply to > competitive > >access scenarios anywhere in the region rather than being defined in > >terms of the current situation in Canada. > > > >Owen > > > >On Jul 27, 2012, at 12:05 PM, ARIN wrote: > > > >> ARIN-prop-179 Reassignments for Third Party Internet Access > >> (TPIA) over Cable > >> > >> ARIN received the following policy proposal. > >> > >> The ARIN Advisory Council (AC) will review the proposal at > their next > >> regularly scheduled meeting (if the period before the next > regularly > >> scheduled meeting is less than 10 days, then the period > may be extended > >> to the subsequent regularly scheduled meeting). The AC > will decide how > >> to utilize the proposal and announce the decision to the PPML. > >> > >> The AC invites everyone to comment on the proposal on the PPML, > >> particularly their support or non-support and the reasoning > >> behind their opinion. Such participation contributes to a thorough > >> vetting and provides important guidance to the AC in their > >>deliberations. > >> > >> Draft Policies and Proposals under discussion can be found at: > >> https://www.arin.net/policy/proposals/index.html > >> > >> The ARIN Policy Development Process can be found at: > >> https://www.arin.net/policy/pdp.html > >> > >> Mailing list subscription information can be found > >> at:https://www.arin.net/mailing_lists/ > >> > >> Regards, > >> > >> Communications and Member Services > >> American Registry for Internet Numbers (ARIN) > >> > >> > >> ## * ## > >> > >> > >> ARIN-prop-179 Reassignments for Third Party Internet Access > >> (TPIA) over Cable > >> > >> On 7/27/12 2:51 PM, Bill Sandiford wrote: > >> > >>> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > >>> > >>> 1. Policy Proposal Name: Reassignments for Third Party > Internet Access > >>> (TPIA) over Cable > >>> 2. Proposal Originator > >>> a. name: Bill Sandiford > >>> b. email: bill at sandiford.com > >>> c. telephone: 905-409-5228 > >>> d. organization: Telnet Communications > >>> > >>> 3. Proposal Version: 1 > >>> 4. Date: July 27, 2012 > >>> 5. Proposal type: new > >>> 6. Policy term: permanent > >>> 7. Policy statement: > >>> Insert new section to NRPM to read as follows: > >>> > >>> 4.2.3.8 Reassignments for Third Party Internet Access > (TPIA) over Cable > >>> > >>> When IP address resources are reassigned by an ISP to an > underlying > >>>cable > >>> carrier for use with TPIA, those addresses shall be > deemed as utilized > >>> once they are assigned to equipment by the underlying > cable carrier. > >>> > >>> 8. Rationale: > >>> A unique situation exists particularly, and perhaps only, in the > >>>Canadian > >>> region that is preventing legitimate ISPs from obtaining > subsequent > >>> allocations of IPv4 addresses for use with the Third > Party Internet > >>>Access > >>> (TPIA) framework that has been mandated by the CRTC > (Canada's version > >>>of > >>> the FCC). Adding this section to the NRPM will allow > ISPs that intend > >>>to > >>> make use of this CRTC mandated framework to obtain the > number resources > >>> that they require but are currently unable to obtain. > >>> 9. Timetable for implementation: immediate > >>> > >>> END OF TEMPLATE > >>> > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > > >_______________________________________________ > >PPML > >You are receiving this message because you are subscribed to > >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >Unsubscribe or manage your mailing list subscription at: > >http://lists.arin.net/mailman/listinfo/arin-ppml > >Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From mueller at syr.edu Sat Jul 28 13:49:39 2012 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 28 Jul 2012 17:49:39 +0000 Subject: [arin-ppml] ARIN-prop-179 Reassignments for Third Party Internet Access (TPIA) over Cable (was: Re: New Policy Proposal) In-Reply-To: References: Message-ID: <855077AC3D7A7147A7570370CA01ECD21D958C@SUEX10-mbx-10.ad.syr.edu> I support this proposal if amended as suggested. Generic wording would be better. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Bill Sandiford > Sent: Friday, July 27, 2012 4:30 PM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-179 Reassignments for Third Party > Internet Access (TPIA) over Cable (was: Re: New Policy Proposal) > > Great points Owen. > > > Happy to work to accomplish what you suggest. > > > On 2012-07-27 4:21 PM, "Owen DeLong" wrote: > > >I'm OK with the intent of this policy. > > > >I'd like to see it expressed in more generic terms and have a > >definition for those terms added to section 2 so that it could apply to > >competitive access scenarios anywhere in the region rather than being > >defined in terms of the current situation in Canada. > > > >Owen > > > >On Jul 27, 2012, at 12:05 PM, ARIN wrote: > > > >> ARIN-prop-179 Reassignments for Third Party Internet Access > >> (TPIA) over Cable > >> > >> ARIN received the following policy proposal. > >> > >> The ARIN Advisory Council (AC) will review the proposal at their next > >> regularly scheduled meeting (if the period before the next regularly > >> scheduled meeting is less than 10 days, then the period may be > >> extended to the subsequent regularly scheduled meeting). The AC will > >> decide how to utilize the proposal and announce the decision to the > PPML. > >> > >> The AC invites everyone to comment on the proposal on the PPML, > >>particularly their support or non-support and the reasoning behind > >>their opinion. Such participation contributes to a thorough vetting > >>and provides important guidance to the AC in their deliberations. > >> > >> Draft Policies and Proposals under discussion can be found at: > >> https://www.arin.net/policy/proposals/index.html > >> > >> The ARIN Policy Development Process can be found at: > >> https://www.arin.net/policy/pdp.html > >> > >> Mailing list subscription information can be found > >> at:https://www.arin.net/mailing_lists/ > >> > >> Regards, > >> > >> Communications and Member Services > >> American Registry for Internet Numbers (ARIN) > >> > >> > >> ## * ## > >> > >> > >> ARIN-prop-179 Reassignments for Third Party Internet Access > >> (TPIA) over Cable > >> > >> On 7/27/12 2:51 PM, Bill Sandiford wrote: > >> > >>> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > >>> > >>> 1. Policy Proposal Name: Reassignments for Third Party Internet > >>> Access > >>> (TPIA) over Cable > >>> 2. Proposal Originator > >>> a. name: Bill Sandiford > >>> b. email: bill at sandiford.com > >>> c. telephone: 905-409-5228 > >>> d. organization: Telnet Communications > >>> > >>> 3. Proposal Version: 1 > >>> 4. Date: July 27, 2012 > >>> 5. Proposal type: new > >>> 6. Policy term: permanent > >>> 7. Policy statement: > >>> Insert new section to NRPM to read as follows: > >>> > >>> 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over > >>> Cable > >>> > >>> When IP address resources are reassigned by an ISP to an underlying > >>>cable carrier for use with TPIA, those addresses shall be deemed as > >>>utilized once they are assigned to equipment by the underlying cable > >>>carrier. > >>> > >>> 8. Rationale: > >>> A unique situation exists particularly, and perhaps only, in the > >>>Canadian region that is preventing legitimate ISPs from obtaining > >>>subsequent allocations of IPv4 addresses for use with the Third > >>>Party Internet Access > >>> (TPIA) framework that has been mandated by the CRTC (Canada's > >>>version of the FCC). Adding this section to the NRPM will allow > >>>ISPs that intend to make use of this CRTC mandated framework to > >>>obtain the number resources that they require but are currently > >>>unable to obtain. > >>> 9. Timetable for implementation: immediate > >>> > >>> END OF TEMPLATE > >>> > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN > >> Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > > >_______________________________________________ > >PPML > >You are receiving this message because you are subscribed to the ARIN > >Public Policy Mailing List (ARIN-PPML at arin.net). > >Unsubscribe or manage your mailing list subscription at: > >http://lists.arin.net/mailman/listinfo/arin-ppml > >Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Sat Jul 28 22:18:44 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 28 Jul 2012 21:18:44 -0500 Subject: [arin-ppml] New Policy Proposal In-Reply-To: References: Message-ID: On 7/27/12, Peter Rocca wrote: This situation should fall under 4.2.3.4.2; allocations for downstream ISPs, without additional special rules. I am not in favor of giving some ISPs a blank check on utilization, by automatically considering their usage justified, as soon as they designated IPs for their equipment. As an LIR / registration authority creating sub-delegations from ARIN allocated resources, the "TPIA" provider (or whatever it's called) should be required to maintain their sub-delegations contact records, and maintain the documentation of usage, and that the subdelegations are efficiently used, based on a utilization criterion in compliance with policy, as any other LIR has to do. > The high-level overview is that the allocation is routed to the TPIA > provider who then carves it up into smaller blocks and routes them to > different 'serving areas' which are geographical groupings of CMTS's. Those > serving areas then have smaller DHCP pools (generally /27's or /28's) > assigned at the node level. End-users are assigned IP's from the DHCP of the > node they are served by. Once the space is provided to the TPIA provider the > ISP no longer has control over the routing, renumbering or specific > assignments within the TPIA network. [snip] -- -JH From owen at delong.com Sun Jul 29 01:56:27 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 28 Jul 2012 22:56:27 -0700 Subject: [arin-ppml] New Policy Proposal In-Reply-To: References: Message-ID: <31C39FEC-073C-40E3-BB21-EA9EABD93B6D@delong.com> Jimmy, This is essentially a case of providers that have to allocate addresses in much the same way as cable ISPs covered under 4.2.3.7.3, but which may not be able to meet the 50% across-the-board requirement. Essentially, this isn't about a blank check, it's about addressing a squeeze created between the regulators (CRTC) and the ability of the incumbent Cable carriers to control the underlying network topology, the competitive TPIA is required to deploy addresses which may not meet current utilization requirements depending on the percentage of market they capture. As I understand it, if you have 3 competing companies in a market, for example, you are virtually guaranteed that at least 2 of them cannot meet the 50% utilization requirement. Owen On Jul 28, 2012, at 7:18 PM, Jimmy Hess wrote: > On 7/27/12, Peter Rocca wrote: > > This situation should fall under 4.2.3.4.2; allocations for > downstream ISPs, without additional special rules. I am not in favor > of giving some ISPs a blank check on utilization, by automatically > considering their usage justified, as soon as they designated IPs for > their equipment. > > As an LIR / registration authority creating sub-delegations from ARIN > allocated resources, the "TPIA" provider (or whatever it's called) > should be required to maintain their sub-delegations contact records, > and maintain the documentation of usage, and that the subdelegations > are efficiently used, based on a utilization criterion in compliance > with policy, as any other LIR has to do. > > > >> The high-level overview is that the allocation is routed to the TPIA >> provider who then carves it up into smaller blocks and routes them to >> different 'serving areas' which are geographical groupings of CMTS's. Those >> serving areas then have smaller DHCP pools (generally /27's or /28's) >> assigned at the node level. End-users are assigned IP's from the DHCP of the >> node they are served by. Once the space is provided to the TPIA provider the >> ISP no longer has control over the routing, renumbering or specific >> assignments within the TPIA network. > [snip] > > -- > -JH > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From john.sweeting at twcable.com Sun Jul 29 17:20:27 2012 From: john.sweeting at twcable.com (Sweeting, John) Date: Sun, 29 Jul 2012 17:20:27 -0400 Subject: [arin-ppml] ARIN-prop-179 Reassignments for Third Party Internet Access (TPIA) over Cable (was: Re: New Policy Proposal) In-Reply-To: <5012E67E.7030903@arin.net> Message-ID: FYI... Kevin Blumberg has been assigned as the Primary Shepherd for this proposal. Cathy Aronson will serve as Secondary Shepherd. On 7/27/12 3:05 PM, "ARIN" wrote: >ARIN-prop-179 Reassignments for Third Party Internet Access >(TPIA) over Cable > >ARIN received the following policy proposal. > >The ARIN Advisory Council (AC) will review the proposal at their next >regularly scheduled meeting (if the period before the next regularly >scheduled meeting is less than 10 days, then the period may be extended >to the subsequent regularly scheduled meeting). The AC will decide how >to utilize the proposal and announce the decision to the PPML. > >The AC invites everyone to comment on the proposal on the PPML, >particularly their support or non-support and the reasoning >behind their opinion. Such participation contributes to a thorough >vetting and provides important guidance to the AC in their deliberations. > >Draft Policies and Proposals under discussion can be found at: >https://www.arin.net/policy/proposals/index.html > >The ARIN Policy Development Process can be found at: >https://www.arin.net/policy/pdp.html > >Mailing list subscription information can be found >at:https://www.arin.net/mailing_lists/ > >Regards, > >Communications and Member Services >American Registry for Internet Numbers (ARIN) > > >## * ## > > >ARIN-prop-179 Reassignments for Third Party Internet Access >(TPIA) over Cable > >On 7/27/12 2:51 PM, Bill Sandiford wrote: > >> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 >> >> 1. Policy Proposal Name: Reassignments for Third Party Internet Access >> (TPIA) over Cable >> 2. Proposal Originator >> a. name: Bill Sandiford >> b. email: bill at sandiford.com >> c. telephone: 905-409-5228 >> d. organization: Telnet Communications >> >> 3. Proposal Version: 1 >> 4. Date: July 27, 2012 >> 5. Proposal type: new >> 6. Policy term: permanent >> 7. Policy statement: >> Insert new section to NRPM to read as follows: >> >> 4.2.3.8 Reassignments for Third Party Internet Access (TPIA) over Cable >> >> When IP address resources are reassigned by an ISP to an underlying >>cable >> carrier for use with TPIA, those addresses shall be deemed as utilized >> once they are assigned to equipment by the underlying cable carrier. >> >> 8. Rationale: >> A unique situation exists particularly, and perhaps only, in the >>Canadian >> region that is preventing legitimate ISPs from obtaining subsequent >> allocations of IPv4 addresses for use with the Third Party Internet >>Access >> (TPIA) framework that has been mandated by the CRTC (Canada's version of >> the FCC). Adding this section to the NRPM will allow ISPs that intend >>to >> make use of this CRTC mandated framework to obtain the number resources >> that they require but are currently unable to obtain. >> 9. Timetable for implementation: immediate >> >> END OF TEMPLATE >> > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jeffmehlenbacher at ipv4marketgroup.com Mon Jul 30 10:13:20 2012 From: jeffmehlenbacher at ipv4marketgroup.com (jeffmehlenbacher at ipv4marketgroup.com) Date: Mon, 30 Jul 2012 07:13:20 -0700 Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing Justification to 60 Months Message-ID: <20120730071320.a9ea43ae5a3fe419ce3b8d7ea1f8bec0.af5efa6dd7.wbe@email17.secureserver.net> David / Scott, Thanks for the background on the decision and your further thoughts on the subject. Jeff Mehlenbacher -------- Original Message -------- Subject: Re: [arin-ppml] Clarification on AC Abandonment of Prop-176: Increasing Justification to 60 Months From: David Farmer Date: Fri, July 27, 2012 1:50 pm To: Scott Leibrand Cc: jeffmehlenbacher at ipv4marketgroup.com, "arin-ppml at arin.net" , David Farmer I'm also very interested in there being a discussion of this issue. However, I voted to abandon this proposal mostly to try to clam things down a bit, wanting to focus the discussion on what the proper next steps are and what the time table should be. Rather than arguing about the merits of this specific proposal especially its 60 month window which I'm highly skeptical of being able to achieve consensus. There are a number of moving pieces here, 24 months only went into effect in February, Inter-RIR transfers should go into effect in the next week or so. While I generally support moving beyond 24 months, I would prefer to be cautious about when to do it. I supported 24 months last fall because while longer than ARIN had normally done, it is not without precedent in the RIR policy space, and it was clear to me that we needed a longer window than 12 months. I'm not aware on any RIR ever having a longer window than 24 months, so 24 months immediately and longer over time seemed like a reasonable but cautious path forward.. On the other I'm not saying that 60 months is complete out of the questions either, there are valid business reasons for that number too. I fully support a 60 month planing horizon for IPv6, I'm just not convinced that 60 months is reasonable for IPv4 at this point in its life cycle. I would like to suggest the proper focus for ARIN policy is not the success or failure of the IPv4 transfer market place, but the success or failure or the Internet market place. I personally believe that they are not mutually exclusive, they are interdependent, but the short and long term health of the Internet market place is way more important than the IPv4 transfer market place, not the other way around. Thanks On 7/27/12 09:22 CDT, Scott Leibrand wrote: > Jeff, > > While the majority of the AC disagreed with my opinion that it would be > best to have this proposal on the docket for discussion in October, > everyone did seem to agree that this was an important issue to discuss. > ARIN does report on registration and transfer activity at each > meeting: I will be particularly interested to see how inter-RIR > transfers play out over the first few months they're available. If/when > you have any insight there, I'd like to hear it as well. > > -Scott > > On Fri, Jul 27, 2012 at 10:12 AM, > wrote: > > Thank you Kevin. It will then be interesting to understand what metrics > are being applied and monitored to determine whether 24 months is an > appropriate duration for justification. The onus for change should not > be on external parties, but rather, ARIN staff should produce statistics > that support the AC's assertion that 24 months is appropriate. > > Jeff Mehlenbacher > > -------- Original Message -------- > Subject: RE: [arin-ppml] Clarification on AC Abandonment of Prop-176: > Increasing Justification to 60 Months > From: Kevin Blumberg > > Date: Fri, July 27, 2012 9:45 am > To: "jeffmehlenbacher at ipv4marketgroup.com > " > >, "arin-ppml at arin.net > " > > > > Jeff, > > It was a mistake on my part. I apologize. It should of read as: > > 176. "The ARIN Advisory Council voted not to accept onto the > docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 months". > The AC feels that with the change to 24 month window in 8.3 having > recently > been implemented, it would be premature to increase the window of > justification. > As well there was concern over 60 month networking plans being > speculative > and difficult to evaluate." > > Thanks, > > Kevin Blumberg > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net > ] On > > Behalf Of jeffmehlenbacher at ipv4marketgroup.com > > > Sent: Friday, July 27, 2012 7:58 AM > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Clarification on AC Abandonment of Prop-176: > Increasing > > Justification to 60 Months > > > > I wonder if a representative of the AC might clarify the > following statement > > relating to the abandonment of Prop-176: > > > > 176. "The ARIN Advisory Council voted not to accept onto the > > docket,ARIN-prop-176 "Increase Needs-Based Justification to 60 > months". > > The AC > > feels that with the change to 24 month window in 8.3 having not > yet been > > implemented, it would be premature to increase the window of > justification. > > As well there was concern over 60 month networking plans being > speculative > > and difficult to evaluate." > > > > I actually do not understand the language above...24 months was > approved > > and implemented on February 10th, 2012. > > > > Any clarification would be appreciated. > > > > Jeff Mehlenbacher > > IPv4 Market Group > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net > ). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you > experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From sethm at rollernet.us Mon Jul 30 13:33:55 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 30 Jul 2012 10:33:55 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <501048AA.2090103@arin.net> References: <501048AA.2090103@arin.net> Message-ID: <5016C583.9010907@rollernet.us> On 7/25/12 12:27 PM, ARIN wrote: > Draft Policy ARIN-2012-5 > Removal of Renumbering Requirement for Small Multihomers > > On 19 July 2012 the ARIN Advisory Council (AC) selected "Removal of > Renumbering Requirement for Small Multihomers" as a draft policy for > adoption discussion on the PPML and at the Public Policy Meeting in > Dallas in October. > > The draft was developed by the AC from policy proposal "ARIN-prop-167 > Removal of Renumbering Requirement for Small Multihomers." Per the > Policy Development Process, the AC submitted text to ARIN for a staff > and legal assessment prior to its selection as a draft policy. Below the > draft policy is the ARIN staff and legal assessment with the text that > was reviewed. The text did not change after the assessment. > > Draft Policy ARIN-2012-5 is below and can be found at: > https://www.arin.net/policy/proposals/2012_5.html > > You are encouraged to discuss Draft Policy 2012-5 on the PPML prior to > the October Public Policy Meeting. Discussion on the list and at ARIN > XXX will be used by the ARIN Advisory Council to determine community > consensus for adopting this as policy. > Strongly OPPOSE. However, I would support this policy if it was modified to allow all existing IPv4 holders to obtain an additional /24 without justification. ~Seth From owen at delong.com Mon Jul 30 14:08:51 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Jul 2012 11:08:51 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <5016C583.9010907@rollernet.us> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> Message-ID: On Jul 30, 2012, at 10:33 , Seth Mattinen wrote: > On 7/25/12 12:27 PM, ARIN wrote: >> Draft Policy ARIN-2012-5 >> Removal of Renumbering Requirement for Small Multihomers >> >> On 19 July 2012 the ARIN Advisory Council (AC) selected "Removal of >> Renumbering Requirement for Small Multihomers" as a draft policy for >> adoption discussion on the PPML and at the Public Policy Meeting in >> Dallas in October. >> >> The draft was developed by the AC from policy proposal "ARIN-prop-167 >> Removal of Renumbering Requirement for Small Multihomers." Per the >> Policy Development Process, the AC submitted text to ARIN for a staff >> and legal assessment prior to its selection as a draft policy. Below the >> draft policy is the ARIN staff and legal assessment with the text that >> was reviewed. The text did not change after the assessment. >> >> Draft Policy ARIN-2012-5 is below and can be found at: >> https://www.arin.net/policy/proposals/2012_5.html >> >> You are encouraged to discuss Draft Policy 2012-5 on the PPML prior to >> the October Public Policy Meeting. Discussion on the list and at ARIN >> XXX will be used by the ARIN Advisory Council to determine community >> consensus for adopting this as policy. >> > > > Strongly OPPOSE. > > However, I would support this policy if it was modified to allow all > existing IPv4 holders to obtain an additional /24 without justification. > Can you elaborate on the logic underlying that proposed modification and/or the connection between the two? It seems rather non-sequitur to me. Owen From sethm at rollernet.us Mon Jul 30 14:49:27 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 30 Jul 2012 11:49:27 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> Message-ID: <5016D737.2010104@rollernet.us> On 7/30/12 11:08 AM, Owen DeLong wrote: > > On Jul 30, 2012, at 10:33 , Seth Mattinen wrote: > >> On 7/25/12 12:27 PM, ARIN wrote: >>> Draft Policy ARIN-2012-5 >>> Removal of Renumbering Requirement for Small Multihomers >>> >>> On 19 July 2012 the ARIN Advisory Council (AC) selected "Removal of >>> Renumbering Requirement for Small Multihomers" as a draft policy for >>> adoption discussion on the PPML and at the Public Policy Meeting in >>> Dallas in October. >>> >>> The draft was developed by the AC from policy proposal "ARIN-prop-167 >>> Removal of Renumbering Requirement for Small Multihomers." Per the >>> Policy Development Process, the AC submitted text to ARIN for a staff >>> and legal assessment prior to its selection as a draft policy. Below the >>> draft policy is the ARIN staff and legal assessment with the text that >>> was reviewed. The text did not change after the assessment. >>> >>> Draft Policy ARIN-2012-5 is below and can be found at: >>> https://www.arin.net/policy/proposals/2012_5.html >>> >>> You are encouraged to discuss Draft Policy 2012-5 on the PPML prior to >>> the October Public Policy Meeting. Discussion on the list and at ARIN >>> XXX will be used by the ARIN Advisory Council to determine community >>> consensus for adopting this as policy. >>> >> >> >> Strongly OPPOSE. >> >> However, I would support this policy if it was modified to allow all >> existing IPv4 holders to obtain an additional /24 without justification. >> > > Can you elaborate on the logic underlying that proposed modification > and/or the connection between the two? > > It seems rather non-sequitur to me. > It is, and that's the point. If a small multihomer is allowed extra resources only because they started out as "small" then others should be able to get another /24 too since many orgs were also "small" at some point. I would also argue that if an org is asking for more than a /24 they're no longer a "small multihomer" anyway. 2012-5 appears to have no merit beyond "renumbering is hard", therefore I oppose it. ~Seth From heather.skanks at gmail.com Mon Jul 30 16:37:57 2012 From: heather.skanks at gmail.com (Heather Schiller) Date: Mon, 30 Jul 2012 16:37:57 -0400 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <5016D737.2010104@rollernet.us> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> Message-ID: Staff can clarify if I get this wrong.. but I believe that deletion of 4.3.6.2 would not have the effect of removing all justification requirements for additional assignment for Small Mulithomers - instead, they would have to qualify for additional assignment under 4.3.6.1 4.3.6.1 Utilization Requirements for Additional Assignment In order to justify an additional assignment, end-users must have efficiently utilized at least 80% of all previous assignments, and must provide ARIN with utilization details. The prefix size for an additional assignment is determined by applying the policies found in Section 4.3 of the NRPM. --Heather On Mon, Jul 30, 2012 at 2:49 PM, Seth Mattinen wrote: > On 7/30/12 11:08 AM, Owen DeLong wrote: >> >> On Jul 30, 2012, at 10:33 , Seth Mattinen wrote: >> >>> On 7/25/12 12:27 PM, ARIN wrote: >>>> Draft Policy ARIN-2012-5 >>>> Removal of Renumbering Requirement for Small Multihomers >>>> >>>> On 19 July 2012 the ARIN Advisory Council (AC) selected "Removal of >>>> Renumbering Requirement for Small Multihomers" as a draft policy for >>>> adoption discussion on the PPML and at the Public Policy Meeting in >>>> Dallas in October. >>>> >>>> The draft was developed by the AC from policy proposal "ARIN-prop-167 >>>> Removal of Renumbering Requirement for Small Multihomers." Per the >>>> Policy Development Process, the AC submitted text to ARIN for a staff >>>> and legal assessment prior to its selection as a draft policy. Below the >>>> draft policy is the ARIN staff and legal assessment with the text that >>>> was reviewed. The text did not change after the assessment. >>>> >>>> Draft Policy ARIN-2012-5 is below and can be found at: >>>> https://www.arin.net/policy/proposals/2012_5.html >>>> >>>> You are encouraged to discuss Draft Policy 2012-5 on the PPML prior to >>>> the October Public Policy Meeting. Discussion on the list and at ARIN >>>> XXX will be used by the ARIN Advisory Council to determine community >>>> consensus for adopting this as policy. >>>> >>> >>> >>> Strongly OPPOSE. >>> >>> However, I would support this policy if it was modified to allow all >>> existing IPv4 holders to obtain an additional /24 without justification. >>> >> >> Can you elaborate on the logic underlying that proposed modification >> and/or the connection between the two? >> >> It seems rather non-sequitur to me. >> > > It is, and that's the point. If a small multihomer is allowed extra > resources only because they started out as "small" then others should be > able to get another /24 too since many orgs were also "small" at some point. > > I would also argue that if an org is asking for more than a /24 they're > no longer a "small multihomer" anyway. 2012-5 appears to have no merit > beyond "renumbering is hard", therefore I oppose it. > > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Mon Jul 30 22:45:39 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 30 Jul 2012 21:45:39 -0500 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <501048AA.2090103@arin.net> References: <501048AA.2090103@arin.net> Message-ID: On 7/25/12, ARIN wrote: > Draft Policy ARIN-2012-5 > Removal of Renumbering Requirement for Small Multihomers I am opposed to the proposal of removal of renumbering requirement for small multihomers. The text of the policy was available, at the time they agreed to do this renumbering, it was their choice, and they walked right into that. If the rationale is that it's not actually being used, then the section that should be reverted is 4.3.2.2: Multihomed Connection Change: "the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. " TO " the minimum block of IP address space assigned is a /22. If assignments smaller than a /22 are needed, multihomed end-users should contact their upstream providers. " Otherwise, the deletion of 4.3.6.2 may cause problems sought to be avoided, occuring, with routing table slot count explosion. -- -JH From owen at delong.com Mon Jul 30 23:44:40 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 30 Jul 2012 20:44:40 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <501048AA.2090103@arin.net> Message-ID: <5647A195-5DFC-4326-B7AC-9FFE722E6C37@delong.com> You do realize that they can: 1. Buy an additional /24 on the open market. 2. Get an additional /24 of PA space from some provider and then route it. 3. Create another organization to obtain the additional space. All of which have the consequence you claim to be trying to avoid. Further, why should the holder of a /16 be allowed to sell it of as /24s, but and organization with a single /24 can't get another /24 or a /23 without returning it? If you want to talk about policies that support routing table bloat, there are much better targets than this one. Owen On Jul 30, 2012, at 19:45 , Jimmy Hess wrote: > On 7/25/12, ARIN wrote: >> Draft Policy ARIN-2012-5 >> Removal of Renumbering Requirement for Small Multihomers > > I am opposed to the proposal of removal of renumbering requirement for > small multihomers. > The text of the policy was available, at the time they agreed to do > this renumbering, it was their choice, and they walked right into > that. > > If the rationale is that it's not actually being used, then the > section that should be reverted is 4.3.2.2: Multihomed Connection > > Change: > "the minimum block of IP address space assigned is a /24. If > assignments smaller than a /24 are needed, multihomed end-users should > contact their upstream providers. " > > TO > " > the minimum block of IP address space assigned is a /22. If > assignments smaller than a /22 are needed, multihomed end-users should > contact their upstream providers. > " > > Otherwise, the deletion of 4.3.6.2 may cause problems sought to > be avoided, occuring, with routing table slot count explosion. > > -- > -JH > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From sethm at rollernet.us Mon Jul 30 23:50:40 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 30 Jul 2012 20:50:40 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> Message-ID: <50175610.2030007@rollernet.us> On 7/30/12 1:48 PM, Owen DeLong wrote: > Seth, > > You appear to misunderstand the nature of the proposal. > > We are not allowing small multihomers to get additional space without justification. > > We are allowing them to get a second /24 instead of having to return the first one and exchange it for a /23. > > The point of any PI subsequent allocation without returning your initial space and exchanging it for a larger block boils down to "renumbering is hard". The question is whether it's worth having some sort of magic line at /22 that pre-supposes that renumbering is sufficiently harder above that threshold to somehow magically justify not returning and renumbering while still requiring it below that threshold. > I understand the nature, I just have a different opinion on the motivation behind it. Are these orgs requesting more address space within a timeframe they could have justified a /22 for in the first place? Are they picking the /24 as an easy entry point and are then upset there's strings attached that could have been avoided? Are hundreds of orgs bumping up against the renumber clause or is it just one or two being loud about it? I see too many appeals to emotion with the use of phrases like "forced to suffer the pain and expense of renumbering" (from ARIN staff comments, which to me indicate an emotional appeal devoid of any technical merit). The rationale statement itself uses "undue burden of renumbering" when it was a known restriction in the beginning. A small multihomer with a /24 was *already* unique just be being able to have a /24 with practically no justification. To get the /24 they just have to say "I'm going to multihome!" and leave it at that. Then later they go "oh, I want more and the internet is being unfair to me". If, for example, they're blowing through their /24 in a matter of months and suddenly want more they should not have received a /24 in the first place. Instead of altering policy to cater to what may simply be bad planning or lack of awareness, I would suggest that this policy be abandoned and in its place have orgs receiving a /24 attest that they acknowledge that a) if they require more space in the future they must return and renumber and b) if they have any inkling of growth they should do their homework first to see if they can justify a /22. ARIN started doing the officer attestation thing in the face of runout, why not educate first instead of jumping straight to altering policy? Or, another suggestion I would consider supporting depending on how it's worded: in place of dropping the renumber requirement completely change it to say that if they request for more space is within 24 months of the original request then they must renumber and return. If they've had their /24 for longer than 24 months only then will the renumber and return requirement be waived. ~Seth From bill at herrin.us Tue Jul 31 00:11:44 2012 From: bill at herrin.us (William Herrin) Date: Tue, 31 Jul 2012 00:11:44 -0400 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <5647A195-5DFC-4326-B7AC-9FFE722E6C37@delong.com> References: <501048AA.2090103@arin.net> <5647A195-5DFC-4326-B7AC-9FFE722E6C37@delong.com> Message-ID: On Mon, Jul 30, 2012 at 11:44 PM, Owen DeLong wrote: > You do realize that they can: > > 1. Buy an additional /24 on the open market. > 2. Get an additional /24 of PA space from some provider and then route it. > 3. Create another organization to obtain the additional space. > > All of which have the consequence you claim to be trying to avoid. These all offer effectively the same push against careless consumption of routing slots as the ARIN policy. #1 due to $$. #2 due to renumbering issues no different than the ARIN policy and #3 due to the expense and difficulty in creating a shell company. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Tue Jul 31 00:27:09 2012 From: bill at herrin.us (William Herrin) Date: Tue, 31 Jul 2012 00:27:09 -0400 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <501048AA.2090103@arin.net> References: <501048AA.2090103@arin.net> Message-ID: On Wed, Jul 25, 2012 at 3:27 PM, ARIN wrote: > Draft Policy ARIN-2012-5 > Removal of Renumbering Requirement for Small Multihomers > > ARIN STAFF ASSESSMENT > > A. ARIN Staff Comments > > The original intent of NRPM 4.3.6.3 was to conserve routing table slots. > However, statistics have shown that NRPM 4.3.6.3 has rarely been used and > that most small multi-homers have not come back to ARIN for additional > space. Therefore, it doesn't seem to be contributing anything significant > toward its original goal. Something is fishy with this reasoning. I can't quite put my finger on it. Oh, I know what it is. It's like deciding to leave the capital in Philadelphia after all once debt assumption is complete because really, what good comes of building a whole new city in the middle of a swamp. The assessment looks at the issue cockeyed. I'd like to see what the rate of successful return for additional addresses is for both /24 holders and /22 holders. If the difference is trivially small, leave the compromise the hell alone. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cgrundemann at gmail.com Tue Jul 31 12:56:03 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 31 Jul 2012 10:56:03 -0600 Subject: [arin-ppml] Updated Text for ARIN-prop-175 Message-ID: Hail PPML, As the primary shepherd for ARIN-prop-175 I am submitting new text (along with a new title) for this policy (below). I believe (and the originator has confirmed) that this text covers the intent of the original proposal. See the updated rationale for more details. Your feedback (or question) is welcomed and appreciated. Cheers, ~Chris ----8<----8<----8<---- Policy Proposal Name: ARIN-prop-175 / Aligning 8.2 and 8.3 Transfer Policy Proposal Originator: Harrison Grundy Proposal Version: 2 Date: 10 July 2012 Proposal type: New Policy term: Permanent Policy statement: Update 8.2. Mergers and Acquisitions to the following: ARIN will consider requests for the transfer of number resources in the case of mergers and acquisitions under the following conditions: * The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. * The new entity (recipient) must provide evidence that they have acquired assets that use the resources transferred from the current registrant (source entity) such that their continued need is justified. ARIN will maintain an up-to-date list of acceptable types of documentation. * The transferred resources will be subject to current ARIN policies. * The recipient entity must sign an RSA. * The minimum transfer size is a /24. * The minimum IPv6 transfer size is a /48. In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy. Rationale: The base intent here is to lower confusion, raise clarity, and level the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from specified transfers and not all of the same rules can apply - but many can and should. Therefor this policy change explicitly adds requirements which do not exist in 8.2 policy text today: Source must be the undisputed current registered holder, recipient must sign an RSA (and is subject to policy), and /24 minimum for IPv4, /48 for IPv6. Two requirements from 8.3 are intentionally left out: First, timed restrictions: Since we are talking about selling equipment and/or customers here, the fact that you just got addresses shouldn't matter. And if your network grows after the sale, there's no reason to stop you from getting more addresses soon after the merger or acquisition. In fact in many cases, the source entity becomes part of the recipient in this type of transfer - and they may well need more addresses before 12 months have passed from the M&A activity. Second, demonstrating a 24 month need is orthogonal in an M&A transfer. Either the network purchased is using the addresses or it is not. Future need is really not part of the equation. Timetable for implementation: Immediate END OF TEMPLATE -- @ChrisGrundemann http://chrisgrundemann.com From alh-ietf at tndh.net Tue Jul 31 13:56:35 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 31 Jul 2012 10:56:35 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <50175610.2030007@rollernet.us> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> Message-ID: <04c101cd6f45$d39a8c40$7acfa4c0$@tndh.net> I support this proposal, because the existing requirement treads dangerously close to the dubious grounds of ARIN taking a position on the 'routing utility' of the assignment at hand. The existing requirement to renumber basically has ARIN stating that a /23 has more utility in the routing world than a pair of /24's. While the point is true from a routing slot consumption perspective (less so from an independent routing policies perspective), ARIN must officially take a hands-off position about the utility of the resource being assigned. This proposed policy puts ARIN back in the position it should have been in all along. At a higher level, isn't it time to stop rearranging the deck chairs? The iceberg has already been hit. IANA has been out of IPv4 pool for 18 months, APnic is in life-boat mode, and RIPE will be in life-boat mode by Nov. 15. The fact that ARIN still has pool is an artifact of timing, not masterful skill at deck-chair arrangement. The routing slots are going to be blown out by market forces, not contained by some fantasy that people will care about a historical free-pool policy with a dubious foundation. Get over it, and move on. Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Seth Mattinen > Sent: Monday, July 30, 2012 8:51 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering > Requirement for Small Multihomers > > On 7/30/12 1:48 PM, Owen DeLong wrote: > > Seth, > > > > You appear to misunderstand the nature of the proposal. > > > > We are not allowing small multihomers to get additional space without > justification. > > > > We are allowing them to get a second /24 instead of having to return the > first one and exchange it for a /23. > > > > The point of any PI subsequent allocation without returning your initial > space and exchanging it for a larger block boils down to "renumbering is > hard". The question is whether it's worth having some sort of magic line at > /22 that pre-supposes that renumbering is sufficiently harder above that > threshold to somehow magically justify not returning and renumbering while > still requiring it below that threshold. > > > > > I understand the nature, I just have a different opinion on the motivation > behind it. Are these orgs requesting more address space within a timeframe > they could have justified a /22 for in the first place? Are they picking the /24 > as an easy entry point and are then upset there's strings attached that could > have been avoided? Are hundreds of orgs bumping up against the renumber > clause or is it just one or two being loud about it? > > I see too many appeals to emotion with the use of phrases like "forced to > suffer the pain and expense of renumbering" (from ARIN staff comments, > which to me indicate an emotional appeal devoid of any technical merit). The > rationale statement itself uses "undue burden of renumbering" when it was > a known restriction in the beginning. A small multihomer with a /24 was > *already* unique just be being able to have a > /24 with practically no justification. To get the /24 they just have to say "I'm > going to multihome!" and leave it at that. Then later they go "oh, I want more > and the internet is being unfair to me". If, for example, they're blowing > through their /24 in a matter of months and suddenly want more they should > not have received a /24 in the first place. > > Instead of altering policy to cater to what may simply be bad planning or lack > of awareness, I would suggest that this policy be abandoned and in its place > have orgs receiving a /24 attest that they acknowledge that > a) if they require more space in the future they must return and renumber > and b) if they have any inkling of growth they should do their homework first > to see if they can justify a /22. ARIN started doing the officer attestation > thing in the face of runout, why not educate first instead of jumping straight > to altering policy? > > Or, another suggestion I would consider supporting depending on how it's > worded: in place of dropping the renumber requirement completely change > it to say that if they request for more space is within 24 months of the original > request then they must renumber and return. If they've had their /24 for > longer than 24 months only then will the renumber and return requirement > be waived. > > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From JOHN at egh.com Tue Jul 31 14:13:26 2012 From: JOHN at egh.com (John Santos) Date: Tue, 31 Jul 2012 14:13:26 -0400 Subject: [arin-ppml] Updated Text for ARIN-prop-175 In-Reply-To: Message-ID: <1120731141122.55734J-100000@Ives.egh.com> On Tue, 31 Jul 2012, Chris Grundemann wrote: First bullet point: > * The source entity must be the current registered holder of the IPv4 > address resources, and not be involved in any dispute as to the status > of those resources. I think this policy section also applies to IPv6 and AS numbers, so it should read "current registered holder of the number resources" rather than explicitly calling out IPv4. Unless there is an explicit reason for this that I'm not getting. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From info at arin.net Tue Jul 31 15:08:02 2012 From: info at arin.net (ARIN) Date: Tue, 31 Jul 2012 15:08:02 -0400 Subject: [arin-ppml] =?windows-1252?q?NRPM_2012=2E3_=96_New_Policies_Imple?= =?windows-1252?q?mented_=28Inter-RIR_Transfers=29?= Message-ID: <50182D12.7020008@arin.net> The following Internet Number Resource Policies have been implemented today: ARIN-2011-1: ARIN Inter-RIR Transfers ARIN-2012-1: Clarifying requirements for IPv4 transfers ARIN-2012-3: ASN Transfers A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2012.3 is effective 31 July 2012. It supersedes the previous version. Guidelines for "8.4 Inter-RIR Transfers to Specified Recipients" are available at: https://www.arin.net/resources/request/transfers_8_4.html ARIN will be hosting an #IPTransfer Twitter Chat with ARIN's President and CEO, John Curran, on 8 August at 2:30 PM (EDT) to answer questions about implementation of the Inter-RIR Transfer Policy. Full details are available at: at: http://teamarin.net/?p=5232 An already implemented global policy has also been added to the NRPM; "ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA." The NRPM is available at: https://www.arin.net/policy/nrpm.html Board minutes are available at: https://www.arin.net/about_us/bot/index.html Draft policies and proposals are 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) From sethm at rollernet.us Tue Jul 31 15:29:11 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 31 Jul 2012 12:29:11 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> Message-ID: <50183207.2070904@rollernet.us> On 7/31/12 12:37 AM, Owen DeLong wrote: > > On Jul 30, 2012, at 20:50 , Seth Mattinen wrote: > >> >> >> I understand the nature, I just have a different opinion on the >> motivation behind it. Are these orgs requesting more address space >> within a timeframe they could have justified a /22 for in the first >> place? Are they picking the /24 as an easy entry point and are then >> upset there's strings attached that could have been avoided? Are >> hundreds of orgs bumping up against the renumber clause or is it just >> one or two being loud about it? >> > > In most cases, no... Usually they're wanting to come back 2-3 years > after getting their /24. Many of these organizations are very small > community networks, neighbornets, and the like. > > No, it's not hundreds of orgs, nor is it one or two. It's a relatively small > number (i.e. not likely to be a significant routing table problem), but more > than a few. > I would argue there's no reason to change policy for a few orgs when the majority aren't affected by current policy in a negative way. There will always be at least one. >> I see too many appeals to emotion with the use of phrases like "forced >> to suffer the pain and expense of renumbering" (from ARIN staff >> comments, which to me indicate an emotional appeal devoid of any >> technical merit). The rationale statement itself uses "undue burden of >> renumbering" when it was a known restriction in the beginning. A small >> multihomer with a /24 was *already* unique just be being able to have a >> /24 with practically no justification. To get the /24 they just have to >> say "I'm going to multihome!" and leave it at that. Then later they go >> "oh, I want more and the internet is being unfair to me". If, for >> example, they're blowing through their /24 in a matter of months and >> suddenly want more they should not have received a /24 in the first place. >> > > It was a restriction put in to get a policy to enable them to get space at > all while appeasing the table-growth fanatics. Now we have evidence > that the table growth fears are utter nonsense, so the burden doesn't > make sense and we're seeking to improve the policy and make it more > even handed for all recipients. > Routing table growth is not a consideration it in my opposition of this policy change. The worst I see with table growth is that /24s could start to become unroutable, but that's not a policy problem either. >> Instead of altering policy to cater to what may simply be bad planning >> or lack of awareness, I would suggest that this policy be abandoned and >> in its place have orgs receiving a /24 attest that they acknowledge that >> a) if they require more space in the future they must return and >> renumber and b) if they have any inkling of growth they should do their >> homework first to see if they can justify a /22. ARIN started doing the >> officer attestation thing in the face of runout, why not educate first >> instead of jumping straight to altering policy? >> > > I don't think it is either bad planning or lack of awareness and I find your > prejudices about this to be somewhat condescending. > So far it's been emotional appeals (I pointed out the two I didn't like seeing) to have the requirement removed, none of which I see as a basis to change policy. > I don't know why you assume they haven't been educated. Knowing doesn't change > the fact that once you assign a bunch of /28s, /29s, and /32s to customers, > it's hard to renumber them all in order to get more space or the fact that > it is an unreasonable burden that unfairly stacks the deck against these > smaller organizations that are NOT a serious threat to the routing table. > I've been there and done that with two PA /24s I don't think it was a burden, unfair, or stacked the deck against me. I expected it from the start and planned accordingly. 12 months was *plenty* of time to renumber. Based on my own experience with renumbering small networks I can't agree with the hardship argument. I would agree that having to renumber a larger network (/22 or shorter) becomes a logistical nightmare, but not a /24 within 12 months. >> Or, another suggestion I would consider supporting depending on how it's >> worded: in place of dropping the renumber requirement completely change >> it to say that if they request for more space is within 24 months of the >> original request then they must renumber and return. If they've had >> their /24 for longer than 24 months only then will the renumber and >> return requirement be waived. > > I could probably live with this. However, would you be willing to compromise > to 18 months? Remember, they have to do the initial justification based on > only 12 months (or in some cases 3). > I'm only aware of a three-month rule for allocations, not end-user assignments, and the /24 is only mentioned under assignments. In 4.3.3 it says "Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection." Are any orgs requesting a /24 using it as their first foray (and if so, how are they showing previous assignments) or are they always coming from longer PA prefixes? A PA /24 can be justified with nothing more than stating "I intend to multihome". I suppose I'd support 18 months but would strongly prefer 24. If an org is requesting additional space near the two year mark then I feel it shows they've planned appropriately. If they're asking for more in short order I feel it's inappropriate because their justification should have said they would have been fine for at least a year (50%), and they can probably justify a /22 to renumber into or should have justified a /22 from the beginning. When I think of a "small" org I think of all the ones I've dealt with in the past and present that could easily survive on a single /24 for years, if not for the life of the org. I *do not* see it as "starter" PI space that they'd quickly outgrow. Place renumber-and-return under a timeframe plus remove the appeals to emotion from the proposal and I'd reconsider my opposition. ~Seth From sethm at rollernet.us Tue Jul 31 15:35:22 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 31 Jul 2012 12:35:22 -0700 Subject: [arin-ppml] Autoreply spam from criticalpath.net Message-ID: <5018337A.3010407@rollernet.us> Is anyone else getting constant autoresponse spam to every single email from donal.ocallaghan at criticalpath.net ? Normally these things silence themselves after one notification. ~Seth From cgrundemann at gmail.com Tue Jul 31 15:40:41 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 31 Jul 2012 13:40:41 -0600 Subject: [arin-ppml] Updated Text for ARIN-prop-175 In-Reply-To: <1120731141122.55734J-100000@Ives.egh.com> References: <1120731141122.55734J-100000@Ives.egh.com> Message-ID: On Tue, Jul 31, 2012 at 12:13 PM, John Santos wrote: > On Tue, 31 Jul 2012, Chris Grundemann wrote: > > First bullet point: > >> * The source entity must be the current registered holder of the IPv4 >> address resources, and not be involved in any dispute as to the status >> of those resources. > > I think this policy section also applies to IPv6 and AS numbers, so > it should read "current registered holder of the number resources" rather > than explicitly calling out IPv4. Unless there is an explicit reason > for this that I'm not getting. Your exactly right John, thanks for the catch - that's a typo on my part and will get fixed asap! ~Chris > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > -- @ChrisGrundemann http://chrisgrundemann.com From owen at delong.com Tue Jul 31 15:56:00 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 31 Jul 2012 12:56:00 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <50183207.2070904@rollernet.us> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> Message-ID: <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> On Jul 31, 2012, at 12:29 , Seth Mattinen wrote: > On 7/31/12 12:37 AM, Owen DeLong wrote: >> >> On Jul 30, 2012, at 20:50 , Seth Mattinen wrote: >> >>> >>> >>> I understand the nature, I just have a different opinion on the >>> motivation behind it. Are these orgs requesting more address space >>> within a timeframe they could have justified a /22 for in the first >>> place? Are they picking the /24 as an easy entry point and are then >>> upset there's strings attached that could have been avoided? Are >>> hundreds of orgs bumping up against the renumber clause or is it just >>> one or two being loud about it? >>> >> >> In most cases, no... Usually they're wanting to come back 2-3 years >> after getting their /24. Many of these organizations are very small >> community networks, neighbornets, and the like. >> >> No, it's not hundreds of orgs, nor is it one or two. It's a relatively small >> number (i.e. not likely to be a significant routing table problem), but more >> than a few. >> > > I would argue there's no reason to change policy for a few orgs when the > majority aren't affected by current policy in a negative way. There will > always be at least one. > I would argue that since the policy as is is not providing any benefit and changing the policy would do no harm and provide benefit, changing policy makes sense. > >>> I see too many appeals to emotion with the use of phrases like "forced >>> to suffer the pain and expense of renumbering" (from ARIN staff >>> comments, which to me indicate an emotional appeal devoid of any >>> technical merit). The rationale statement itself uses "undue burden of >>> renumbering" when it was a known restriction in the beginning. A small >>> multihomer with a /24 was *already* unique just be being able to have a >>> /24 with practically no justification. To get the /24 they just have to >>> say "I'm going to multihome!" and leave it at that. Then later they go >>> "oh, I want more and the internet is being unfair to me". If, for >>> example, they're blowing through their /24 in a matter of months and >>> suddenly want more they should not have received a /24 in the first place. >>> >> >> It was a restriction put in to get a policy to enable them to get space at >> all while appeasing the table-growth fanatics. Now we have evidence >> that the table growth fears are utter nonsense, so the burden doesn't >> make sense and we're seeking to improve the policy and make it more >> even handed for all recipients. >> > > Routing table growth is not a consideration it in my opposition of this > policy change. The worst I see with table growth is that /24s could > start to become unroutable, but that's not a policy problem either. > Nonetheless, that is the sole and only reason justifying the current renumbering requirement and its cutoff at /22. > >>> Instead of altering policy to cater to what may simply be bad planning >>> or lack of awareness, I would suggest that this policy be abandoned and >>> in its place have orgs receiving a /24 attest that they acknowledge that >>> a) if they require more space in the future they must return and >>> renumber and b) if they have any inkling of growth they should do their >>> homework first to see if they can justify a /22. ARIN started doing the >>> officer attestation thing in the face of runout, why not educate first >>> instead of jumping straight to altering policy? >>> >> >> I don't think it is either bad planning or lack of awareness and I find your >> prejudices about this to be somewhat condescending. >> > > So far it's been emotional appeals (I pointed out the two I didn't like > seeing) to have the requirement removed, none of which I see as a basis > to change policy. I see the argument for the existing policy as purely emotional appeal at this point. > > >> I don't know why you assume they haven't been educated. Knowing doesn't change >> the fact that once you assign a bunch of /28s, /29s, and /32s to customers, >> it's hard to renumber them all in order to get more space or the fact that >> it is an unreasonable burden that unfairly stacks the deck against these >> smaller organizations that are NOT a serious threat to the routing table. >> > > I've been there and done that with two PA /24s I don't think it was a > burden, unfair, or stacked the deck against me. I expected it from the > start and planned accordingly. 12 months was *plenty* of time to > renumber. Based on my own experience with renumbering small networks I > can't agree with the hardship argument. I would agree that having to > renumber a larger network (/22 or shorter) becomes a logistical > nightmare, but not a /24 within 12 months. > I've been there and done that too. Many times in a variety of circumstances. It really depends on the nature of the network and a number of factors unrelated to the size. When you have a customer-affecting renumbering requirement, it is nearly inevitable that you lose some customers in the process. If the customer has to renumber, they start considering what other changes they can make while involved in network upheaval anyway. Nature of the beast. If you're going from /24 to /23 and risk having to do this again to go to /22, then you're at even more of a disadvantage as your customers will be looking to renumber into a place where they won't face forced renumbering again. > >>> Or, another suggestion I would consider supporting depending on how it's >>> worded: in place of dropping the renumber requirement completely change >>> it to say that if they request for more space is within 24 months of the >>> original request then they must renumber and return. If they've had >>> their /24 for longer than 24 months only then will the renumber and >>> return requirement be waived. >> >> I could probably live with this. However, would you be willing to compromise >> to 18 months? Remember, they have to do the initial justification based on >> only 12 months (or in some cases 3). >> > > > I'm only aware of a three-month rule for allocations, not end-user > assignments, and the /24 is only mentioned under assignments. > Fair point. Nonetheless, doubling the anticipated lifespan still seems excessive to me. > In 4.3.3 it says "Requesters must show exactly how previous address > assignments have been utilized and must provide appropriate details to > verify their one-year growth projection." Are any orgs requesting a /24 > using it as their first foray (and if so, how are they showing previous > assignments) or are they always coming from longer PA prefixes? A PA /24 > can be justified with nothing more than stating "I intend to multihome". Most of the organizations I am aware of are showing that they are using 100% of no previous assignments and that they are deploying a sufficiently large network to justify a multi-homed /24. Often this is done with a combination of peering contracts, invoices for hardware, and other such evidence of deployment. Thus, it is usually their initial assignment rather than using prior assignments as justification. Admittedly, my experience is limited to those organizations whose applications I am familiar with or involved in. ARIN may have other data, but they would be unable to share same. > I suppose I'd support 18 months but would strongly prefer 24. If an org > is requesting additional space near the two year mark then I feel it > shows they've planned appropriately. If they're asking for more in short > order I feel it's inappropriate because their justification should have > said they would have been fine for at least a year (50%), and they can > probably justify a /22 to renumber into or should have justified a /22 > from the beginning. They were given space based on their 12 month growth plan. How is asking for more a year later poor planning? If you run out a year after you got space based on your one-year growth projection, I'd call that extremely good planning. If you run out after 18 months, I'd call that optimistic growth projections. If it takes you two years to fill up your "one year growth plan", I'm not sure I can see that as good planning. Your attitude here mystifies me. > When I think of a "small" org I think of all the ones I've dealt with in > the past and present that could easily survive on a single /24 for > years, if not for the life of the org. I *do not* see it as "starter" PI > space that they'd quickly outgrow. There are many sizes of organizations in the real world. Some small multi-homed organizations can, indeed, survive on a /24 for many years and may well be doing so. Others have a one-year growth projection that really maxes out their /24 and will grow beyond it in about one year. Others will grow slower or faster than that. Sometimes you have a realistic growth projection that exceeds a /24 in a year, but you cannot convince ARIN of the realism of that plan. I would not call having to get more space in 6 months because of that poor planning. However, I can accept the argument for an 18 month moratorium, but would strongly prefer 12 or less, if any. > Place renumber-and-return under a timeframe plus remove the appeals to > emotion from the proposal and I'd reconsider my opposition. > Noted. Owen From sethm at rollernet.us Tue Jul 31 16:51:40 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 31 Jul 2012 13:51:40 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> Message-ID: <5018455C.5080901@rollernet.us> One thing that came to me while thinking about this is someone churning through additional /24 requests as fast as they can because it's just that much easier to justify and meet the mark on a /24 compared to shorter prefixes. I would see that as abusive and prefer not to open the door to that or other other bad behavior I can't think of because I'm not of that mind. ~Seth From michael+ppml at burnttofu.net Tue Jul 31 16:40:23 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Tue, 31 Jul 2012 13:40:23 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <50183207.2070904@rollernet.us> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> Message-ID: <501842B7.2000509@burnttofu.net> On 7/31/12 12:29 PM, Seth Mattinen wrote: > I've been there and done that with two PA /24s I don't think it was a > burden, unfair, or stacked the deck against me. I expected it from the > start and planned accordingly. 12 months was *plenty* of time to > renumber. Based on my own experience with renumbering small networks I > can't agree with the hardship argument. I would agree that having to > renumber a larger network (/22 or shorter) becomes a logistical > nightmare, but not a /24 within 12 months. As this paragraph shows, renumbering is not a zero-cost activity, for an entity of any size. It required planning and some level of work by a clueful person or persons. I agree with you that phrases like "renumbering is hard," "burdensome," or "renumbering sucks" do not necessarily form the basis of good policy. However, good policy shouldn't impose costs on smaller actors while allowing larger actors to impose costs on the "routing table commons." There should be more uniformity in such restrictions. Moreover, building on Tony's points, the /24 horse left the barn long ago, well before the policy that 2012-5 seeks to mitigate was put into NRPM. For these reasons, I support 2012-5. michael From sethm at rollernet.us Tue Jul 31 17:13:38 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 31 Jul 2012 14:13:38 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <501842B7.2000509@burnttofu.net> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> <501842B7.2000509@burnttofu.net> Message-ID: <50184A82.40209@rollernet.us> On 7/31/12 1:40 PM, Michael Sinatra wrote: > On 7/31/12 12:29 PM, Seth Mattinen wrote: > >> I've been there and done that with two PA /24s I don't think it was a >> burden, unfair, or stacked the deck against me. I expected it from the >> start and planned accordingly. 12 months was *plenty* of time to >> renumber. Based on my own experience with renumbering small networks I >> can't agree with the hardship argument. I would agree that having to >> renumber a larger network (/22 or shorter) becomes a logistical >> nightmare, but not a /24 within 12 months. > > As this paragraph shows, renumbering is not a zero-cost activity, for an > entity of any size. It required planning and some level of work by a > clueful person or persons. I agree with you that phrases like > "renumbering is hard," "burdensome," or "renumbering sucks" do not > necessarily form the basis of good policy. However, good policy > shouldn't impose costs on smaller actors while allowing larger actors to > impose costs on the "routing table commons." There should be more > uniformity in such restrictions. Moreover, building on Tony's points, > the /24 horse left the barn long ago, well before the policy that 2012-5 > seeks to mitigate was put into NRPM. > > For these reasons, I support 2012-5. > Justification, planning, and "doing your homework" should be a fundamental basis of any request to ARIN for resources. I'm fine with /24s. I understand routing table size is argued a lot but that's honestly not part of my thought process here. In fact, I argued heavily with Verizon about carrying IPv6 /48s (which they do now). If anything I'd like to see IPv4 assignments specifically for anycasting (/23 deagg'd or /24) allowed by policy. But I'd prefer not make /24s like unlimited free candy on a low shelf. ~Seth From sethm at rollernet.us Tue Jul 31 17:22:03 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 31 Jul 2012 14:22:03 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> Message-ID: <50184C7B.7060706@rollernet.us> On 7/31/12 12:56 PM, Owen DeLong wrote: >> When I think of a "small" org I think of all the ones I've dealt with in >> the past and present that could easily survive on a single /24 for >> years, if not for the life of the org. I *do not* see it as "starter" PI >> space that they'd quickly outgrow. > > There are many sizes of organizations in the real world. Some small > multi-homed organizations can, indeed, survive on a /24 for many years > and may well be doing so. Others have a one-year growth projection that > really maxes out their /24 and will grow beyond it in about one year. > Others will grow slower or faster than that. > > Sometimes you have a realistic growth projection that exceeds a /24 > in a year, but you cannot convince ARIN of the realism of that plan. > I would not call having to get more space in 6 months because of that > poor planning. However, I can accept the argument for an 18 month > moratorium, but would strongly prefer 12 or less, if any. > I would concede to 12 months since 4.3.3 only requires the requesting org to plan one year in advance. ~Seth From owen at delong.com Tue Jul 31 21:17:55 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 31 Jul 2012 18:17:55 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <50184C7B.7060706@rollernet.us> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> <50184C7B.7060706@rollernet.us> Message-ID: There's been a lot of discussion here about this between Seth and I. How do others feel about putting in a restriction that subsequent non-renumbered requests wait one-year after submitting the prior request? Generally, I oppose the idea of a waiting period as an unnecessary inconvenience both to the requestor and to staff which provides little, if any benefit to the community. However, if that will help us move the policy proposal forward with greater consensus, then I would consider it an acceptable tradeoff. I would like to hear more from the community about whether such a modification to this proposal would increase or decrease your willingness to support it. Owen On Jul 31, 2012, at 14:22 , Seth Mattinen wrote: > On 7/31/12 12:56 PM, Owen DeLong wrote: >>> When I think of a "small" org I think of all the ones I've dealt with in >>> the past and present that could easily survive on a single /24 for >>> years, if not for the life of the org. I *do not* see it as "starter" PI >>> space that they'd quickly outgrow. >> >> There are many sizes of organizations in the real world. Some small >> multi-homed organizations can, indeed, survive on a /24 for many years >> and may well be doing so. Others have a one-year growth projection that >> really maxes out their /24 and will grow beyond it in about one year. >> Others will grow slower or faster than that. >> >> Sometimes you have a realistic growth projection that exceeds a /24 >> in a year, but you cannot convince ARIN of the realism of that plan. >> I would not call having to get more space in 6 months because of that >> poor planning. However, I can accept the argument for an 18 month >> moratorium, but would strongly prefer 12 or less, if any. >> > > > I would concede to 12 months since 4.3.3 only requires the requesting > org to plan one year in advance. > > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From george.herbert at gmail.com Tue Jul 31 21:32:25 2012 From: george.herbert at gmail.com (George Herbert) Date: Tue, 31 Jul 2012 18:32:25 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> <50184C7B.7060706@rollernet.us> Message-ID: On Tue, Jul 31, 2012 at 6:17 PM, Owen DeLong wrote: > There's been a lot of discussion here about this between Seth > and I. How do others feel about putting in a restriction that subsequent > non-renumbered requests wait one-year after submitting the prior > request? > > Generally, I oppose the idea of a waiting period as an unnecessary > inconvenience both to the requestor and to staff which provides little, > if any benefit to the community. However, if that will help us move the > policy proposal forward with greater consensus, then I would consider > it an acceptable tradeoff. I would like to hear more from the community > about whether such a modification to this proposal would increase or > decrease your willingness to support it. I would like a clearer articulation of the objections. If this does enable "handing out /24s like candy" in some meaningful way then I oppose it, but I am not so far seeing it. Unless the objections are made more clear I would support it as originally posted. -- -george william herbert george.herbert at gmail.com From sethm at rollernet.us Tue Jul 31 21:50:24 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 31 Jul 2012 18:50:24 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> <50184C7B.7060706@rollernet.us> Message-ID: <50188B60.5000702@rollernet.us> On 7/31/12 6:32 PM, George Herbert wrote: > On Tue, Jul 31, 2012 at 6:17 PM, Owen DeLong wrote: >> There's been a lot of discussion here about this between Seth >> and I. How do others feel about putting in a restriction that subsequent >> non-renumbered requests wait one-year after submitting the prior >> request? >> >> Generally, I oppose the idea of a waiting period as an unnecessary >> inconvenience both to the requestor and to staff which provides little, >> if any benefit to the community. However, if that will help us move the >> policy proposal forward with greater consensus, then I would consider >> it an acceptable tradeoff. I would like to hear more from the community >> about whether such a modification to this proposal would increase or >> decrease your willingness to support it. > > I would like a clearer articulation of the objections. > > If this does enable "handing out /24s like candy" in some meaningful > way then I oppose it, but I am not so far seeing it. Unless the > objections are made more clear I would support it as originally > posted. > > I've posed several objections, can you pinpoint the ones you feel are not clear? ~Seth From sethm at rollernet.us Tue Jul 31 21:57:48 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 31 Jul 2012 18:57:48 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> <50184C7B.7060706@rollernet.us> Message-ID: <50188D1C.4080800@rollernet.us> On 7/31/12 6:17 PM, Owen DeLong wrote: > There's been a lot of discussion here about this between Seth > and I. How do others feel about putting in a restriction that subsequent > non-renumbered requests wait one-year after submitting the prior > request? > > Generally, I oppose the idea of a waiting period as an unnecessary > inconvenience both to the requestor and to staff which provides little, > if any benefit to the community. However, if that will help us move the > policy proposal forward with greater consensus, then I would consider > it an acceptable tradeoff. I would like to hear more from the community > about whether such a modification to this proposal would increase or > decrease your willingness to support it. > If the goal is uniformity and equality for the benefit of all orgs, then I would also support including a modification to 4.2.1.5 and 4.2.2.2 to lower minimum multihomed allocations to /24 concurrent with removing the renumber requirement in 4.3.2.2 without adding any sort of waiting period. ~Seth From alh-ietf at tndh.net Tue Jul 31 22:04:30 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 31 Jul 2012 19:04:30 -0700 Subject: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers In-Reply-To: <50188B60.5000702@rollernet.us> References: <501048AA.2090103@arin.net> <5016C583.9010907@rollernet.us> <5016D737.2010104@rollernet.us> <616EFC83-E7B0-4B79-833A-84772D309522@delong.com> <50175610.2030007@rollernet.us> <8DFECC16-DC69-499F-BDA0-442A41465277@delong.com> <50183207.2070904@rollernet.us> <5DE99852-4665-4C9D-B005-67858A2CBCD7@delong.com> <50184C7B.7060706@rollernet.us> <50188B60.5000702@rollernet.us> Message-ID: <051e01cd6f89$fcff39c0$f6fdad40$@tndh.net> While I think the proposal is fine as written, if it does need tweaking to move forward, how about shifting the focus from 'required' renumbering to 'encouraged'. One way to implement that would be to set different utilization requirements. Something like; if you renumber you only need to meet 2/3 the utilization of when you don't. I don't particularly support a waiting requirement, but if one needs to exist, one year seems more than long enough. There are O^ 250k /24's in the ARIN pool. You can't process them fast enough for 'handing out like candy' to be a problem. Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Seth Mattinen > Sent: Tuesday, July 31, 2012 6:50 PM > To: George Herbert; ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering > Requirement for Small Multihomers > > On 7/31/12 6:32 PM, George Herbert wrote: > > On Tue, Jul 31, 2012 at 6:17 PM, Owen DeLong > wrote: > >> There's been a lot of discussion here about this between Seth and I. > >> How do others feel about putting in a restriction that subsequent > >> non-renumbered requests wait one-year after submitting the prior > >> request? > >> > >> Generally, I oppose the idea of a waiting period as an unnecessary > >> inconvenience both to the requestor and to staff which provides > >> little, if any benefit to the community. However, if that will help > >> us move the policy proposal forward with greater consensus, then I > >> would consider it an acceptable tradeoff. I would like to hear more > >> from the community about whether such a modification to this proposal > >> would increase or decrease your willingness to support it. > > > > I would like a clearer articulation of the objections. > > > > If this does enable "handing out /24s like candy" in some meaningful > > way then I oppose it, but I am not so far seeing it. Unless the > > objections are made more clear I would support it as originally > > posted. > > > > > > I've posed several objections, can you pinpoint the ones you feel are not > clear? > > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues.