From susannah.gray at gmail.com Tue May 2 14:41:18 2017 From: susannah.gray at gmail.com (Susannah Gray) Date: Tue, 2 May 2017 11:41:18 -0700 Subject: [arin-ppml] AFRINIC Board Ratifies In-Region IPv4 Transfer Proposal Message-ID: <4967d051-03c4-7366-cb49-2cc3467aefa8@gmail.com> FYI The AFRINIC Board has ratified policy proposal AFPUB-2016-V4-003-DRAFT03, "IPv4 Resources Transfer Within the AFRINIC Region": https://www.afrinic.net/en/library/news/2085-afrinic-board-ratifies-policy-proposal-ipv4-resources-transfer-within-the-afrinic-region This is the first AFRINIC policy that makes the transfer of IPv4/legacy IPv4 space possible. Regards, Susannah -- Susannah Gray Communications Consultant | Writer | Editor www.susegray.com - President & Chair San Francisco-Bay Area Internet Society Chapter www.sfbayisoc.org From Alison.WOOD at oregon.gov Wed May 3 13:34:32 2017 From: Alison.WOOD at oregon.gov (WOOD Alison * DAS) Date: Wed, 3 May 2017 17:34:32 +0000 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates Message-ID: The ARIN Draft Policy 2017-1 shepherds working with the original author have updated the problem statement and added clarification to section 8.5.5. The AC would like feedback on the proposed updated problem statement and modification to 8.5.5. We encourage community members to comment on the proposed updates. Problem Statement (revised): Some number of organizations may be uncomfortable making speculative forward projections (that are now required under NRPM section 8 for purposes of transfer request approval) and prefer that there be available a more certain approach based solely on extrapolation of their existing IPv4 number usage trend. And adding the following text to the end of 8.5.5 Organizations may qualify for an additional block by using a projection of their address use from 6-24 months of allocations or assignments just prior to the transfer request. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Wed May 3 13:49:42 2017 From: mike at iptrading.com (Mike Burns) Date: Wed, 3 May 2017 13:49:42 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: References: Message-ID: <009501d2c435$a4cd6280$ee682780$@iptrading.com> Hi Alison, We have done 400+ transfers and have never heard of this problem from any buyer. Buyers are far more concerned with ensuring supply and what it will cost. I don't see the value in more Section 8 clutter. Anybody in the world with any sort of concern about demonstrating need by whatever arcane formula can avail themselves of the needs-free policy in RIPE. Open an account there, buy what you need, use them anywhere. Plus no transfer fees! That's the workaround. Even better would be to address this problem through excision of the needs test from ARIN transfer policy, rendering the NRPM simpler, easier to use, and less cluttered by pointless artifacts from the free-pool era. So I don't support the proposal in its revised form. Regards, Mike Burns From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of WOOD Alison * DAS Sent: Wednesday, May 03, 2017 1:35 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates The ARIN Draft Policy 2017-1 shepherds working with the original author have updated the problem statement and added clarification to section 8.5.5. The AC would like feedback on the proposed updated problem statement and modification to 8.5.5. We encourage community members to comment on the proposed updates. Problem Statement (revised): Some number of organizations may be uncomfortable making speculative forward projections (that are now required under NRPM section 8 for purposes of transfer request approval) and prefer that there be available a more certain approach based solely on extrapolation of their existing IPv4 number usage trend. And adding the following text to the end of 8.5.5 Organizations may qualify for an additional block by using a projection of their address use from 6-24 months of allocations or assignments just prior to the transfer request. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrl at lodden.com Thu May 4 12:52:06 2017 From: jrl at lodden.com (jrl) Date: Thu, 4 May 2017 17:52:06 +0100 Subject: [arin-ppml] =?utf-8?q?=E2=9D=A4amazing_day?= Message-ID: <1469594538.20170504195206@lodden.com> Hello, We've had an amazing day today and we just wanted to share some information about places we've visited, just take a look http://dcomm1684.celsiustickets.com Faithfully, jrl From: arin-ppml [mailto:arin-ppml at arin.net] Sent: Thursday, May 04, 2017 12:52 PM To: jrl at lodden.com Subject: Better not get a tan. I really would not categorize this as a "WTF" moment type of game. Plus the horrible fact nothing you do in the game changes anything. No matter how great/horrible a detective you are nothing changes, and if the game decides your stuck it gives you the answers through your partner. (Sorry, being a film noire fan I had my hopes destroyed for a good detective game by this title.) Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AA5F0871FBD62E029A5744795BE3BFD0.jpg Type: image/jpeg Size: 20829 bytes Desc: not available URL: From narten at us.ibm.com Fri May 5 00:53:32 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 05 May 2017 00:53:32 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201705050453.v454rWQk024667@rotala.raleigh.ibm.com> Total of 3 messages in the last 7 days. script run at: Fri May 5 00:53:27 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 33.33% | 1 | 49.75% | 17213 | mike at iptrading.com 33.33% | 1 | 27.98% | 9681 | alison.wood at oregon.gov 33.33% | 1 | 22.27% | 7704 | susannah.gray at gmail.com --------+------+--------+----------+------------------------ 100.00% | 3 |100.00% | 34598 | Total From austin.murkland at qscend.com Fri May 5 16:06:04 2017 From: austin.murkland at qscend.com (Austin Murkland) Date: Fri, 5 May 2017 16:06:04 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: References: Message-ID: 8.5.5. Block size Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN. Organizations may qualify for an additional block by using a projection of their address use from 6-24 months of allocations or assignments just prior to the transfer request. I think between 8.3, 8.5.5, and 8.5.6 this still becomes a hazardous guessing game that doesn't account for unexpected growth. While i'm not fully comfortable with immediate excision of the needs tests, I do believe that relaxing them to a significant degree would be a step in the right direction. If you're going to re-align an organization's projection timeframe to 6-24 months, it only makes sense to align 8.3 and 8.4 with that new standard of 6 months as well. That way even if an organization is wrong, there's more than 1 opportunity to correct it within a year (assuming their only source is ARIN); and increases in pricing or address availability are limited to a 6 months timeframe. Is there any interest in moving towards a slow-end of the needs based tests; where the minimum 12 months (in 8.3, 8.4, and 8.5.5) becomes 6, after a review period the 6 becomes 3 and later the 3 becomes none as the transfer market is monitored throughout the slow-end to ensure this isn't enabling the negative scenario(s) it's designed to prevent? -Austin On Wed, May 3, 2017 at 1:34 PM, WOOD Alison * DAS wrote: > The ARIN Draft Policy 2017-1 shepherds working with the original author > have updated the problem statement and added clarification to section > 8.5.5. The AC would like feedback on the proposed updated problem > statement and modification to 8.5.5. We encourage community members to > comment on the proposed updates. > > Problem Statement (revised): > Some number of organizations may be uncomfortable making speculative > forward projections (that are now required under NRPM section 8 for > purposes of transfer request approval) and prefer that there be available a > more certain approach based solely on extrapolation of their existing IPv4 > number usage trend. > > And adding the following text to the end of 8.5.5 > > Organizations may qualify for an additional block by using a projection of > their address use from 6-24 months of allocations or assignments just prior > to the transfer request. > > Thank you! > > > > > _______________________________________________ > 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 mike at iptrading.com Fri May 5 16:36:14 2017 From: mike at iptrading.com (Mike Burns) Date: Fri, 5 May 2017 16:36:14 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: References: Message-ID: <010b01d2c5df$3d968820$b8c39860$@iptrading.com> Is there any interest in moving towards a slow-end of the needs based tests; where the minimum 12 months (in 8.3, 8.4, and 8.5.5) becomes 6, after a review period the 6 becomes 3 and later the 3 becomes none as the transfer market is monitored throughout the slow-end to ensure this isn't enabling the negative scenario(s) it's designed to prevent? -Austin Hi Austin, I would support a phase out of the needs test, but I am not sure how you would monitor the transfer market to detect the enabling of negative scenarios. I would be curious to know what those scenarios are and how they would be detected. If the scenario is market manipulation/speculation, we have evidence of years of needs-free transfers in RIPE from which to draw conclusions. And analysis of those transfers does not reveal speculation, instead it shows the most dynamic market of any registry. But I like your idea to trend away from needs tests. I believe that the price of the addresses in the transfer market provides the conservation that the needs test was designed to provide in the free pool era. Likewise the holding periods which were intended to prevent flipping of addresses. I myself authored that waiting period for transfers in ARIN, but I am not even sure why flipping is a problem at all. APNIC has never had a holding period. We have many sellers whom we have to advise to hold on to their un-needed addresses until their holding period elapses. This takes addresses out of inventory and prevents their timely use by those who express their real need for the addresses through payment of money. I know that we would be an entity that would like to purchase address blocks and then resell them in smaller pieces. Looking at allocation history, many /16s were allocated, but looking at transfer history, most transfers are for smaller blocks. Many /16 holders are not as competent or desirous as we are in processing many sales, and prefer just one transaction. So we would like to buy a /16 in a single transaction (good for the seller), use our experience to ease the transactions for the many small block buyers out there (good for these buyers), and make money on the price differential between large and small blocks (good for us). (Bad for routing table size, but that?s inevitable. Blocks, like Humpty Dumpty, can only be broken down.) I believe that address stewards, fearful of market manipulation that could be harmful to the Internet, have adopted policies whose intents are benign, but whose effects are negative. It?s time to acknowledge the information from APNIC and RIPE related to these market-stifling policies, and consider adjusting our policies to reflect that information. I had an economics professor, Paul Samuelson, who had a famous quote which is relevant to stewards like us: ?When my information changes, I alter my conclusions. What do you do, sir?? Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Mon May 8 12:27:12 2017 From: jschiller at google.com (Jason Schiller) Date: Mon, 8 May 2017 12:27:12 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: <009501d2c435$a4cd6280$ee682780$@iptrading.com> References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> Message-ID: Comments in line. On Wed, May 3, 2017 at 1:49 PM, Mike Burns wrote: > Hi Alison, > > > > We have done 400+ transfers and have never heard of this problem from any > buyer. > 1. Going forward, organizations requiring a /15 or less per year would likely just use the simplified doubling approach (2016-3) , as such this policy proposal would not be helpful (and current policy not a problem). 2. This problem would only impact organizations that are large enough to have their own relationship with ARIN. The organization's internal struggle with creating a justification that they can stand behind, and meet ARIN requirements would generally be kept internal to such an organization. I expect these organizations would have already secured pre-approval prior to engaging an outside organization to complete a transfer. 3. This problem has only emerged since the implementation of ARIN-2016-6 which occurred on 02/21/2017. Transfers prior to this date could have been justified under slow start in section 4. - How many of the 400+ transfers has the approval been completed post 02/21/2017? - Of those, how many transfer are larger than a /16? (or the transfer in question brings the org to over a /15 worth of transfers in the previous 1 year rolling window) - Of those, how many have you consulted on putting together the justification for transfer approval? So yes, I am not surprised that in your 400+ transfers you have not seen this as an issue. Thant doesn't mean it is not an issue. While I expect that well over 90% will make use of either NRPM 8.5.4 or 2016-3 (maybe even as Owen suggests 2016-3 "obviates the need for [2017-1] by and large."), there are still a small number of requests that are for larger than a /15 per year. To not address that small amount of requests suggests we as a community do not care about their need. Prior to 02/21/2017 those requests had the option to base their two year need solely on the recent past consumption rate. These requests will now be forced to use a purely future looking projection, with no clear guidance on what justification ARIN will accept, or how much additional information, back and forth discussion, and time will be required, nor the ability to predict the likelihood that a request should or should not be approved. Google is a data driven company. In a data driven company it may be easier to simply base a future looking growth on a real measure of current consumption rate, knowing that this will necessarily result in a short fall because you are only requesting IP addressed based on the current rate, and not the current growth rate. In the absence of real data, people will often guess. Some people guess better, some worse. Some guesses are based on intricate algorithms, real data, and Fermi maths, others are just what feel right. Either type can be multiple orders of magnitude off, or in the right ballpark. Do we really want to encourage data driven companies who previously requested less IP space then they needed because their requests have always been based on a real measure of consumption, and not addressing speculative growth, to instead require them to guess about the future? Especially noting that if they guess too low, the penalty is running out of IPs, and if they guess to high there is no penalty (except if they buy a surplus and end up with IPs that were bought which go unused)? > Buyers are far more concerned with ensuring supply and what it will cost. > > I don?t see the value in more Section 8 clutter. > I would encourage you to no think of this as more clutter in section 8, but rather addressing a justification that was previously support under section 4, and now has to be mirrored into section 8 to continue to support the legitimacy of this type of a request in order to address over-pruning. > Anybody in the world with any sort of concern about demonstrating need by > whatever arcane formula can avail themselves of the needs-free policy in > RIPE. > > Open an account there, buy what you need, use them anywhere. Plus no > transfer fees! > > > That?s the workaround. Even better would be to address this problem > through excision of the needs test from ARIN transfer policy, rendering the > NRPM simpler, easier to use, and less cluttered by pointless artifacts > from the free-pool era. > We attempted this with 2016-3 where the needs justification was simplified, and it has been addressed for those organizations that need less than a /15 per year. Initially there was no cap on this proposal, but the community pushed back, and said we don't need to make things more simple for large organizations. That, and a severing transfers from section 4 resulted in removal of the option to use slow start. So now we have to deal with adding slow-start complexity (for large ISPs) to transfer policy. Please note, this does not add any new required test, nor would it force anyone who qualifies under the current policy to get rejected. If you oppose this on the grounds of less clutter, then I suggest you should have provided more support for moving 2016-3 forward without a cap. ___Jason > > So I don?t support the proposal in its revised form. > > > > Regards, > Mike Burns > > > > > > > > > > > > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *WOOD > Alison * DAS > *Sent:* Wednesday, May 03, 2017 1:35 PM > *To:* arin-ppml at arin.net > *Subject:* [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for > Transfers proposed updates > > > > The ARIN Draft Policy 2017-1 shepherds working with the original author > have updated the problem statement and added clarification to section > 8.5.5. The AC would like feedback on the proposed updated problem > statement and modification to 8.5.5. We encourage community members to > comment on the proposed updates. > > > > Problem Statement (revised): > > Some number of organizations may be uncomfortable making speculative > forward projections (that are now required under NRPM section 8 for > purposes of transfer request approval) and prefer that there be available a > more certain approach based solely on extrapolation of their existing IPv4 > number usage trend. > > > > And adding the following text to the end of 8.5.5 > > > > Organizations may qualify for an additional block by using a projection of > their address use from 6-24 months of allocations or assignments just prior > to the transfer request. > > > > Thank you! > > > > > > > > _______________________________________________ > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon May 8 12:41:50 2017 From: jcurran at arin.net (John Curran) Date: Mon, 8 May 2017 16:41:50 +0000 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> Message-ID: <972738F0-329B-4BFD-948C-3DBF22350D43@arin.net> On 8 May 2017, at 11:27 AM, Jason Schiller > wrote: Comments in line. ... In the absence of real data, people will often guess. Some people guess better, some worse. Some guesses are based on intricate algorithms, real data, and Fermi maths, others are just what feel right. Either type can be multiple orders of magnitude off, or in the right ballpark. Do we really want to encourage data driven companies who previously requested less IP space then they needed because their requests have always been based on a real measure of consumption, and not addressing speculative growth, to instead require them to guess about the future? Jason - Is there a reason that data-driven companies cannot make use of the existing transfer policy, and create their anticipated 24-month need based on their actual past utilization? I am having difficulty understanding why policy is needed specifically to enable use of one particular type of forward-looking projection (i.e. forecasts based on past utilization.) Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Mon May 8 13:25:42 2017 From: mike at iptrading.com (Mike Burns) Date: Mon, 8 May 2017 13:25:42 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> Message-ID: <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> Hi Jason, Sorry for the top-post, but I will be short with three points. 1. A forecast based on history is still a guess 2. We don?t need ANY of section 4 in section 8 because free pool <> transfers 3. Maybe we could do a show-of-hands ala the community networks rule to see if this matters to anybody, because if it matters to very few people (2%?) and if there is a workaround, then IMO we shouldn?t waste NRPM space on it. Regards, Mike From: Jason Schiller [mailto:jschiller at google.com] Sent: Monday, May 08, 2017 12:27 PM To: Mike Burns Cc: WOOD Alison * DAS ; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates Comments in line. On Wed, May 3, 2017 at 1:49 PM, Mike Burns > wrote: Hi Alison, We have done 400+ transfers and have never heard of this problem from any buyer. 1. Going forward, organizations requiring a /15 or less per year would likely just use the simplified doubling approach (2016-3) , as such this policy proposal would not be helpful (and current policy not a problem). 2. This problem would only impact organizations that are large enough to have their own relationship with ARIN. The organization's internal struggle with creating a justification that they can stand behind, and meet ARIN requirements would generally be kept internal to such an organization. I expect these organizations would have already secured pre-approval prior to engaging an outside organization to complete a transfer. 3. This problem has only emerged since the implementation of ARIN-2016-6 which occurred on 02/21/2017. Transfers prior to this date could have been justified under slow start in section 4. - How many of the 400+ transfers has the approval been completed post 02/21/2017? - Of those, how many transfer are larger than a /16? (or the transfer in question brings the org to over a /15 worth of transfers in the previous 1 year rolling window) - Of those, how many have you consulted on putting together the justification for transfer approval? So yes, I am not surprised that in your 400+ transfers you have not seen this as an issue. Thant doesn't mean it is not an issue. While I expect that well over 90% will make use of either NRPM 8.5.4 or 2016-3 (maybe even as Owen suggests 2016-3 "obviates the need for [2017-1] by and large."), there are still a small number of requests that are for larger than a /15 per year. To not address that small amount of requests suggests we as a community do not care about their need. Prior to 02/21/2017 those requests had the option to base their two year need solely on the recent past consumption rate. These requests will now be forced to use a purely future looking projection, with no clear guidance on what justification ARIN will accept, or how much additional information, back and forth discussion, and time will be required, nor the ability to predict the likelihood that a request should or should not be approved. Google is a data driven company. In a data driven company it may be easier to simply base a future looking growth on a real measure of current consumption rate, knowing that this will necessarily result in a short fall because you are only requesting IP addressed based on the current rate, and not the current growth rate. In the absence of real data, people will often guess. Some people guess better, some worse. Some guesses are based on intricate algorithms, real data, and Fermi maths, others are just what feel right. Either type can be multiple orders of magnitude off, or in the right ballpark. Do we really want to encourage data driven companies who previously requested less IP space then they needed because their requests have always been based on a real measure of consumption, and not addressing speculative growth, to instead require them to guess about the future? Especially noting that if they guess too low, the penalty is running out of IPs, and if they guess to high there is no penalty (except if they buy a surplus and end up with IPs that were bought which go unused)? Buyers are far more concerned with ensuring supply and what it will cost. I don?t see the value in more Section 8 clutter. I would encourage you to no think of this as more clutter in section 8, but rather addressing a justification that was previously support under section 4, and now has to be mirrored into section 8 to continue to support the legitimacy of this type of a request in order to address over-pruning. Anybody in the world with any sort of concern about demonstrating need by whatever arcane formula can avail themselves of the needs-free policy in RIPE. Open an account there, buy what you need, use them anywhere. Plus no transfer fees! That?s the workaround. Even better would be to address this problem through excision of the needs test from ARIN transfer policy, rendering the NRPM simpler, easier to use, and less cluttered by pointless artifacts from the free-pool era. We attempted this with 2016-3 where the needs justification was simplified, and it has been addressed for those organizations that need less than a /15 per year. Initially there was no cap on this proposal, but the community pushed back, and said we don't need to make things more simple for large organizations. That, and a severing transfers from section 4 resulted in removal of the option to use slow start. So now we have to deal with adding slow-start complexity (for large ISPs) to transfer policy. Please note, this does not add any new required test, nor would it force anyone who qualifies under the current policy to get rejected. If you oppose this on the grounds of less clutter, then I suggest you should have provided more support for moving 2016-3 forward without a cap. ___Jason So I don?t support the proposal in its revised form. Regards, Mike Burns From: ARIN-PPML [mailto: arin-ppml-bounces at arin.net] On Behalf Of WOOD Alison * DAS Sent: Wednesday, May 03, 2017 1:35 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates The ARIN Draft Policy 2017-1 shepherds working with the original author have updated the problem statement and added clarification to section 8.5.5. The AC would like feedback on the proposed updated problem statement and modification to 8.5.5. We encourage community members to comment on the proposed updates. Problem Statement (revised): Some number of organizations may be uncomfortable making speculative forward projections (that are now required under NRPM section 8 for purposes of transfer request approval) and prefer that there be available a more certain approach based solely on extrapolation of their existing IPv4 number usage trend. And adding the following text to the end of 8.5.5 Organizations may qualify for an additional block by using a projection of their address use from 6-24 months of allocations or assignments just prior to the transfer request. Thank you! _______________________________________________ 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. -- _______________________________________________________ Jason Schiller|NetOps| jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Mon May 8 13:42:08 2017 From: jschiller at google.com (Jason Schiller) Date: Mon, 8 May 2017 13:42:08 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: <972738F0-329B-4BFD-948C-3DBF22350D43@arin.net> References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <972738F0-329B-4BFD-948C-3DBF22350D43@arin.net> Message-ID: John, In a word no. One could imagine a justification that says something like: - on 12/05 we got a /16 -- (assume we demonstrated efficient utilization of currently held space at this time) - on 05/05 we demonstrated efficient use of the this space -- (assume efficient utilization of the new /16 is justifiable) -- (assume efficient utilization of previous held space is justifiable) - at current consumption rate, a /14 represents a two year supply - we anticipate that our product will continue growing for the for see-able future Can we have a /14 please? --- Technically the request above makes no prediction about the future. I suspect such a request would get approved, but it would be nice to formalize it. The difference is in the past, under slow star, it was very clear what was required and what ARIN would accept. The future-looking requirements are by necessity less clear, and hence the result is less predictable, and can unexpectedly take longer. Separation form section 4, removed a clearly stated, clearly understood, well exercised, acceptable set of justification. This policy is an attempt to re-instate that there is at least one very clearly defined justification that ARIN finds acceptable, and hence at least one clearly defined and predictable path Beyond that it tweaks the pre-existing slow start in two ways: 1. it opens it up to end-users 2. it makes allowances for the possibility of a pause due to the inability to get timely transfers. ___Jason On Mon, May 8, 2017 at 12:41 PM, John Curran wrote: > On 8 May 2017, at 11:27 AM, Jason Schiller wrote: > > > Comments in line. > ... > In the absence of real data, people will often guess. Some people guess > better, some > worse. Some guesses are based on intricate algorithms, real data, and > Fermi maths, > others are just what feel right. Either type can be multiple orders of > magnitude off, or > in the right ballpark. > > Do we really want to encourage data driven companies who previously > requested less IP > space then they needed because their requests have always been based on a > real > measure of consumption, and not addressing speculative growth, to instead > require them > to guess about the future? > > > Jason - > > Is there a reason that data-driven companies cannot make use of the > existing transfer > policy, and create their anticipated 24-month need based on their > actual past utilization? > > I am having difficulty understanding why policy is needed specifically > to enable use of > one particular type of forward-looking projection (i.e. forecasts > based on past utilization.) > > Thanks, > /John > > John Curran > President and CEO > ARIN > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Mon May 8 14:12:28 2017 From: jschiller at google.com (Jason Schiller) Date: Mon, 8 May 2017 14:12:28 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> Message-ID: Mike, No need for apologizes on top posting... your response are very clear and effective 1. yes, I agree, a forecast based on history is still a forecast. And either type can equally lead to correct and wrong predictions. These two statements are different: I believe we will have more than 1 million customers by the end of 2018. Since 01/2017 we have added 42,000 customers per month on average. At this rate we will have more than 1 million customers by the end of 2018. 2. The community is split wrt what parts of section are needed to support transfers. Some suggested lowering efficiency to 50% would help to offset not having a TPA policy. 3. I'm not sure I personally feel comfortable saying extra words that only help a small percentage of the members are a waste of space. What percentage of requests fall under TPA? I'd counter wrt community networks, the discussion was that the policy was never used. I wonder if staff has any insight as to how often slow-start type justification is used for transfers? Can staff sort transfer authorization requests into the following categorized? A. Current Consumption Rate Request considers only current rate, projected out over a time window. - e.g. we used a /15 over the last 12 months. at this rate a /14 is a two year supply. B. Growth rate Request considers current growth rate, projected over a time window. - e.g. we used a /16 between 01/15 - 12/2015 we used a /15 over the last 12 months. at this rate we double every year. if we keep yearly doubling, then a /14 and a /13 is a two year supply. C. Hi bread Request considers current growth rate, but requests more than the current rate over some time horizon due to other reasons for acceleration, such as entry into new markets, increase in manufacturing of hand sets, etc. D. Future looking Request is purely future looking. - e.g. We anticipate the sale of 1 Million handsets over the next year. 50-80% of those handsets will use our application and require an IP. Do you see all of these types? Is one type more dominate then the others? Is one type more successful than others? Does one type require more transaction time? more back and forth? __Jason On Mon, May 8, 2017 at 1:25 PM, Mike Burns wrote: > Hi Jason, > > > > Sorry for the top-post, but I will be short with three points. > > > > 1. A forecast based on history is still a guess > > 2. We don?t need ANY of section 4 in section 8 because free pool <> > transfers > > 3. Maybe we could do a show-of-hands ala the community networks > rule to see if this matters to anybody, because if it matters to very few > people (2%?) and if there is a workaround, then IMO we shouldn?t waste NRPM > space on it. > > > > Regards, > > Mike > > > > > > *From:* Jason Schiller [mailto:jschiller at google.com] > *Sent:* Monday, May 08, 2017 12:27 PM > *To:* Mike Burns > *Cc:* WOOD Alison * DAS ; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start > for Transfers proposed updates > > > > Comments in line. > > > > On Wed, May 3, 2017 at 1:49 PM, Mike Burns wrote: > > Hi Alison, > > > > We have done 400+ transfers and have never heard of this problem from any > buyer. > > > > 1. Going forward, organizations requiring a /15 or less per year would > likely just use the simplified > > doubling approach (2016-3) , as such this policy proposal would not be > helpful > > (and current policy not a problem). > > > > 2. This problem would only impact organizations that are large enough to > have their own relationship with > > ARIN. The organization's internal struggle with creating a justification > that they can stand behind, > > and meet ARIN requirements would generally be kept internal to such an > organization. I expect > > these organizations would have already secured pre-approval prior to > engaging an outside organization > > to complete a transfer. > > > > 3. This problem has only emerged since the implementation of ARIN-2016-6 > which occurred on > > 02/21/2017. Transfers prior to this date could have been justified under > slow start in section 4. > > > > - How many of the 400+ transfers has the approval been completed > post 02/21/2017? > > > > - Of those, how many transfer are larger than a /16? > > (or the transfer in question brings the org to over a /15 worth of > transfers in the previous > > 1 year rolling window) > > > > - Of those, how many have you consulted on putting together the > justification for transfer approval? > > > > So yes, I am not surprised that in your 400+ transfers you have not seen > this as an issue. > > > > Thant doesn't mean it is not an issue. > > > > While I expect that well over 90% will make use of either NRPM 8.5.4 or > 2016-3 > > (maybe even as Owen suggests 2016-3 "obviates the need for [2017-1] by and > large."), > > there are still a small number of requests that are for larger than a /15 > per year. > > > > To not address that small amount of requests suggests we as a community do > not > > care about their need. > > > > Prior to 02/21/2017 those requests had the option to base their two year > need solely > > on the recent past consumption rate. These requests will now be forced to > use a > > purely future looking projection, with no clear guidance on what > justification ARIN > > will accept, or how much additional information, back and forth > discussion, and time > > will be required, nor the ability to predict the likelihood that a request > should or should > > not be approved. > > > > Google is a data driven company. > > > > In a data driven company it may be easier to simply base a future looking > growth on a > > real measure of current consumption rate, knowing that this will > necessarily result in a > > short fall because you are only requesting IP addressed based on the > current rate, and > > not the current growth rate. > > > > In the absence of real data, people will often guess. Some people guess > better, some > > worse. Some guesses are based on intricate algorithms, real data, and > Fermi maths, > > others are just what feel right. Either type can be multiple orders of > magnitude off, or > > in the right ballpark. > > > > Do we really want to encourage data driven companies who previously > requested less IP > > space then they needed because their requests have always been based on a > real > > measure of consumption, and not addressing speculative growth, to instead > require them > > to guess about the future? Especially noting that if they guess too low, > the penalty is > > running out of IPs, and if they guess to high there is no penalty (except > if they buy a > > surplus and end up with IPs that were bought which go unused)? > > > > > > Buyers are far more concerned with ensuring supply and what it will cost. > > I don?t see the value in more Section 8 clutter. > > > > I would encourage you to no think of this as more clutter in section 8, > but rather addressing > > a justification that was previously support under section 4, and now has > to be mirrored into > > section 8 to continue to support the legitimacy of this type of a request > in order to address > > over-pruning. > > > > Anybody in the world with any sort of concern about demonstrating need by > whatever arcane formula can avail themselves of the needs-free policy in > RIPE. > > Open an account there, buy what you need, use them anywhere. Plus no > transfer fees! > > > > That?s the workaround. Even better would be to address this problem > through excision of the needs test from ARIN transfer policy, rendering the > NRPM simpler, easier to use, and less cluttered by pointless artifacts > from the free-pool era. > > > > We attempted this with 2016-3 where the needs justification was > simplified, and it has > > been addressed for those organizations that need less than a /15 per year. > > > > Initially there was no cap on this proposal, but the community pushed > back, and said > > we don't need to make things more simple for large organizations. That, > and a severing > > transfers from section 4 resulted in removal of the option to use slow > start. > > > > So now we have to deal with adding slow-start complexity (for large ISPs) > to transfer > > policy. > > > > Please note, this does not add any new required test, nor would it force > anyone who > > qualifies under the current policy to get rejected. > > > > If you oppose this on the grounds of less clutter, then I suggest you > should have > > provided more support for moving 2016-3 forward without a cap. > > > > ___Jason > > > > > > So I don?t support the proposal in its revised form. > > > > Regards, > Mike Burns > > > > > > > > > > > > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *WOOD > Alison * DAS > *Sent:* Wednesday, May 03, 2017 1:35 PM > *To:* arin-ppml at arin.net > *Subject:* [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for > Transfers proposed updates > > > > The ARIN Draft Policy 2017-1 shepherds working with the original author > have updated the problem statement and added clarification to section > 8.5.5. The AC would like feedback on the proposed updated problem > statement and modification to 8.5.5. We encourage community members to > comment on the proposed updates. > > > > Problem Statement (revised): > > Some number of organizations may be uncomfortable making speculative > forward projections (that are now required under NRPM section 8 for > purposes of transfer request approval) and prefer that there be available a > more certain approach based solely on extrapolation of their existing IPv4 > number usage trend. > > > > And adding the following text to the end of 8.5.5 > > > > Organizations may qualify for an additional block by using a projection of > their address use from 6-24 months of allocations or assignments just prior > to the transfer request. > > > > Thank you! > > > > > > > > > _______________________________________________ > 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. > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon May 8 17:39:26 2017 From: jcurran at arin.net (John Curran) Date: Mon, 8 May 2017 21:39:26 +0000 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> Message-ID: <66188C9C-39E8-4EF9-ADD7-CFE99BF342CD@arin.net> On 8 May 2017, at 1:12 PM, Jason Schiller > wrote: .. Can staff sort transfer authorization requests into the following categorized? A. Current Consumption Rate Request considers only current rate, projected out over a time window. - e.g. we used a /15 over the last 12 months. at this rate a /14 is a two year supply. B. Growth rate Request considers current growth rate, projected over a time window. - e.g. we used a /16 between 01/15 - 12/2015 we used a /15 over the last 12 months. at this rate we double every year. if we keep yearly doubling, then a /14 and a /13 is a two year supply. C. Hi bread Request considers current growth rate, but requests more than the current rate over some time horizon due to other reasons for acceleration, such as entry into new markets, increase in manufacturing of hand sets, etc. D. Future looking Request is purely future looking. - e.g. We anticipate the sale of 1 Million handsets over the next year. 50-80% of those handsets will use our application and require an IP. Do you see all of these types? Is one type more dominate then the others? Is one type more successful than others? Does one type require more transaction time? more back and forth? Jason - We have not been cataloging transfer requests via such criteria, and hence cannot provide these statistics for transfer requests that have been made to date. We can begin categorizing them and recording them for future transfers, but would need to specifically augment the processes and systems accordingly. Such work would need to be prioritized against other existing enhancement requests, so submit a suggestion via the ARIN Consultation and Suggestion Process if you consider this functionality a priority. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon May 8 17:56:09 2017 From: jcurran at arin.net (John Curran) Date: Mon, 8 May 2017 21:56:09 +0000 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <972738F0-329B-4BFD-948C-3DBF22350D43@arin.net> Message-ID: <20C69E35-A6D2-4FF8-9803-E997A6E1C0F4@arin.net> On 8 May 2017, at 12:42 PM, Jason Schiller wrote: > > John, > > In a word no. > > One could imagine a justification that says something like: > - on 12/05 we got a /16 > -- (assume we demonstrated efficient utilization of currently > held space at this time) > - on 05/05 we demonstrated efficient use of the this space > -- (assume efficient utilization of the new /16 is justifiable) > -- (assume efficient utilization of previous held space is justifiable) > - at current consumption rate, a /14 represents a two year supply > - we anticipate that our product will continue growing for the for see-able future > > Can we have a /14 please? > --- > > Technically the request above makes no prediction about the future. Jason - Regardless of whether you call it a prediction or not, your extension of your consumption rate to establish your 'two year supply? meets NRPM 8.5.5?s requirement for ?documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months.? This aligns with the clear policy intent of transfer policy as adopted by the community; so long as an officer of the organization attests to the documentation, such requests will be approved. Thanks, /John John Curran President and CEO ARIN From jschiller at google.com Tue May 9 10:11:25 2017 From: jschiller at google.com (Jason Schiller) Date: Tue, 9 May 2017 10:11:25 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: <66188C9C-39E8-4EF9-ADD7-CFE99BF342CD@arin.net> References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> <66188C9C-39E8-4EF9-ADD7-CFE99BF342CD@arin.net> Message-ID: John, Having personally stood up at many members meetings, and requested my fees be increased or even doubled if that is what it take to continue on-going IT development and enhancements... I do NOT think it is a worthwhile investment to add IT support to catalog the type of transfer request justification. It is even less important going forward with the new policy changes which eliminates the need for smaller than /15 per year requests to use this justification. I will not be submitting a ACSP. I was hoping there was a general sense from processing requests that might help us to understand if certain request pathways seem like that are never used, inconsequentially used, used a bit, used more than one would think, used quite a bit, used more than half the time, used most frequently, etc. I don't think it is worthwhile to labor this point. ___Jason On Mon, May 8, 2017 at 5:39 PM, John Curran wrote: > On 8 May 2017, at 1:12 PM, Jason Schiller wrote: > > .. > Can staff sort transfer authorization requests into the following > categorized? > > A. Current Consumption Rate > Request considers only current rate, projected out over a time window. > - e.g. we used a /15 over the last 12 months. at this rate a /14 is > a two year supply. > > B. Growth rate > Request considers current growth rate, projected over a time window. > - e.g. we used a /16 between 01/15 - 12/2015 > we used a /15 over the last 12 months. > at this rate we double every year. > if we keep yearly doubling, then a /14 and a /13 is a two > year supply. > > C. Hi bread > Request considers current growth rate, but requests more than the > current rate over some time horizon due to other reasons for > acceleration, > such as entry into new markets, increase in manufacturing of hand > sets, etc. > > > D. Future looking > Request is purely future looking. > - e.g. We anticipate the sale of 1 Million handsets over the next year. > 50-80% of those handsets will use our application and require > an IP. > > Do you see all of these types? > Is one type more dominate then the others? > Is one type more successful than others? > Does one type require more transaction time? more back and forth? > > > Jason - > > We have not been cataloging transfer requests via such criteria, and > hence cannot provide these statistics for transfer requests that have > been made to date. We can begin categorizing them and recording > them for future transfers, but would need to specifically augment the > processes and systems accordingly. Such work would need to be > prioritized against other existing enhancement requests, so submit > a suggestion via the ARIN Consultation and Suggestion Process > if you consider > this functionality a priority. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Tue May 9 10:15:45 2017 From: jschiller at google.com (Jason Schiller) Date: Tue, 9 May 2017 10:15:45 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: <20C69E35-A6D2-4FF8-9803-E997A6E1C0F4@arin.net> References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <972738F0-329B-4BFD-948C-3DBF22350D43@arin.net> <20C69E35-A6D2-4FF8-9803-E997A6E1C0F4@arin.net> Message-ID: John, Thank you for the statement. This makes me feel much more comfortable. I wish such text was clearly spelled out in the policy (as I think that is good for the community), but I will happily take such text as part of the unwritten rules of the NRPM. Would you say the policy proposal as written is an operation non-op for ARIN staff? ___Jason On Mon, May 8, 2017 at 5:56 PM, John Curran wrote: > On 8 May 2017, at 12:42 PM, Jason Schiller wrote: > > > > John, > > > > In a word no. > > > > One could imagine a justification that says something like: > > - on 12/05 we got a /16 > > -- (assume we demonstrated efficient utilization of currently > > held space at this time) > > - on 05/05 we demonstrated efficient use of the this space > > -- (assume efficient utilization of the new /16 is justifiable) > > -- (assume efficient utilization of previous held space is > justifiable) > > - at current consumption rate, a /14 represents a two year supply > > - we anticipate that our product will continue growing for the for > see-able future > > > > Can we have a /14 please? > > --- > > > > Technically the request above makes no prediction about the future. > > Jason - > > Regardless of whether you call it a prediction or not, your extension of > your consumption rate > to establish your 'two year supply? meets NRPM 8.5.5?s requirement for > ?documentation to > ARIN which details the use of at least 50% of the requested IPv4 block > size within 24 months.? > > This aligns with the clear policy intent of transfer policy as adopted by > the community; so long > as an officer of the organization attests to the documentation, such > requests will be approved. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue May 9 10:31:44 2017 From: jcurran at arin.net (John Curran) Date: Tue, 9 May 2017 14:31:44 +0000 Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <972738F0-329B-4BFD-948C-3DBF22350D43@arin.net> <20C69E35-A6D2-4FF8-9803-E997A6E1C0F4@arin.net> Message-ID: On 9 May 2017, at 10:15 AM, Jason Schiller > wrote: John, Thank you for the statement. This makes me feel much more comfortable. I wish such text was clearly spelled out in the policy (as I think that is good for the community), but I will happily take such text as part of the unwritten rules of the NRPM. Would you say the policy proposal as written is an operation non-op for ARIN staff? Intersting question. The policy proposal would result in some very specific procedures for processing requests that utilize that new policy text, and so it is not a ?no-op?; there would be work to implement both internally with processes and in public-facing materials. The more interesting question is whether the policy proposal would enable approval of any transfer requests that would not already be approved under existing policy ? that appears to be quite unlikely. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Wed May 10 12:19:01 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 10 May 2017 12:19:01 -0400 (EDT) Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> Message-ID: I did not attend ARIN39, but did watch the video of the discussion regarding this Draft Policy. I have looked thru the archives, and have not seen any previous discussion of 2017-3 since its announcement, thus I start the discussion on the list. I am in favor of the policy changes, except for 3.6.7, which would remove non responsive contacts from the database. While I have no issue with marking any set of contacts as non-responsive, actually removing the last known contact is wrong. While the information may be stale, and the record will state this fact, it still provides an important clue if an investigation regarding that record needs to be taken due to law enforcement needs or other vital purposes. Therefore, until a POC is replaced with another known good POC for that resource or the resource is otherwise revoked, I think the old data should remain for every resource. In fact, until the resource is reassigned to a new holder, there may be good reason to leave it with a notation it has been revoked, giving LIRs a easy way to verify the truth of what might be a forged LOA for the resource. The most important change in this proposal is allowing legacy contacts to be updated without the signing of an RSA. Of course many at ARIN cannot understand why legacy holders are not rushing to sign, but looking at it from the other side, I fully understand why the lawyers for such firms will not allow it. Please change policy to allow these POCs to update their information. Overall, this will be the best decision. Of course with IPv6 resources, we are starting with a clean slate and even legacy IPv4 holders require a RSA for these resources. However, on the other side of the coin, because of the larger default blocks allocated, it might be years, or even decades until they return for more resources, making it even more likely than now for POC's to go stale. Since the billing contact is often different than the other network POC's, that does not help in keeping the other POC's current. During the discussion, a major worldwide content management firm disagreed regarding removal of notification to downstream assignment contacts who have no relationship to ARIN. He found that this is often the only way he discovers POC records created by his many upstream ISP's around the world. Of course this is only a symptom of what is the TRUE issue, which is allowing the adding of POC records by upstream ISP's for assignments that must be registered at ARIN without first obtaining affirmative consent of the contacts who are added. This is also why the spam laws might be said to apply, since these contacts never gave their consent. Changing the proceedure to require the POC accept before permitting the record to be added is best practice. Of course such contacts need to be able to edit their own POC record, even if there is no contract with ARIN. I understand is an operational issue, not a policy issue. This would also allow the contact to steer all such ARIN assignment contacts to a single ARIN handle, instead of ending up with one handle per assignment, often using an address that was never meant to be used for that purpose. Removing the requirement for ARIN to validate the downstream assignments is best, if needed let the RIR's be in charge of this, as they know their customer and the circuits the resources are attached to, and are best equipped to keep this part of the database up to date. ARIN resources ar better used elsewhere. Albert Erdmann Network Administrator Paradise On Line Inc. From scottleibrand at gmail.com Wed May 10 12:35:58 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 10 May 2017 09:35:58 -0700 Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> Message-ID: On Wed, May 10, 2017 at 9:19 AM, wrote: > > During the discussion, a major worldwide content management firm disagreed > regarding removal of notification to downstream assignment contacts who > have no relationship to ARIN. He found that this is often the only way he > discovers POC records created by his many upstream ISP's around the world. > > Of course this is only a symptom of what is the TRUE issue, which is > allowing the adding of POC records by upstream ISP's for assignments that > must be registered at ARIN without first obtaining affirmative consent of > the contacts who are added. This is also why the spam laws might be said > to apply, since these contacts never gave their consent. Changing the > procedure to require the POC accept before permitting the record to be > added is best practice. Of course such contacts need to be able to edit > their own POC record, even if there is no contract with ARIN. I understand > is an operational issue, not a policy issue. This would also allow the > contact to steer all such ARIN assignment contacts to a single ARIN handle, > instead of ending up with one handle per assignment, often using an address > that was never meant to be used for that purpose. > Strong +1 for this. My impression is that everyone seems to think this change would be a major improvement, and would address much of the long-term problem here. Question for ARIN staff: What would be the best way to get the ball rolling on these operational changes? Should we submit an ACSP suggestion? Is this PPML discussion sufficient? Does the AC need to ask staff to prioritize this work? Or do we need policy directing ARIN to do so? -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Wed May 10 12:54:54 2017 From: daveid at panix.com (David Huberman) Date: Wed, 10 May 2017 12:54:54 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> Message-ID: <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> I really appreciate your email and your thoughts, thank you. Do you have an opinion on the proposal's requirement to remove rDNS delegation records when POCs go unresponsive? As an advisory council member, I really want to hear many operator views on the rDNS portion. Thank you, David Sent from my iPhone > On May 10, 2017, at 12:19 PM, hostmaster at uneedus.com wrote: > > I did not attend ARIN39, but did watch the video of the discussion regarding this Draft Policy. I have looked thru the archives, and have not seen any previous discussion of 2017-3 since its announcement, thus I start the discussion on the list. > > I am in favor of the policy changes, except for 3.6.7, which would remove non responsive contacts from the database. While I have no issue with marking any set of contacts as non-responsive, actually removing the last known contact is wrong. While the information may be stale, and the record will state this fact, it still provides an important clue if an investigation regarding that record needs to be taken due to law enforcement needs or other vital purposes. Therefore, until a POC is replaced with another known good POC for that resource or the resource is otherwise revoked, I think the old data should remain for every resource. In fact, until the resource is reassigned to a new holder, there may be good reason to leave it with a notation it has been revoked, giving LIRs a easy way to verify the truth of what might be a forged LOA for the resource. > > The most important change in this proposal is allowing legacy contacts to be updated without the signing of an RSA. Of course many at ARIN cannot understand why legacy holders are not rushing to sign, but looking at it from the other side, I fully understand why the lawyers for such firms will not allow it. Please change policy to allow these POCs to update their information. Overall, this will be the best decision. > > Of course with IPv6 resources, we are starting with a clean slate and even legacy IPv4 holders require a RSA for these resources. However, on the other side of the coin, because of the larger default blocks allocated, it might be years, or even decades until they return for more resources, making it even more likely than now for POC's to go stale. Since the billing contact is often different than the other network POC's, that does not help in keeping the other POC's current. > > During the discussion, a major worldwide content management firm disagreed regarding removal of notification to downstream assignment contacts who have no relationship to ARIN. He found that this is often the only way he discovers POC records created by his many upstream ISP's around the world. > > Of course this is only a symptom of what is the TRUE issue, which is allowing the adding of POC records by upstream ISP's for assignments that must be registered at ARIN without first obtaining affirmative consent of the contacts who are added. This is also why the spam laws might be said to apply, since these contacts never gave their consent. Changing the proceedure to require the POC accept before permitting the record to be added is best practice. Of course such contacts need to be able to edit their own POC record, even if there is no contract with ARIN. I understand is an operational issue, not a policy issue. This would also allow the contact to steer all such ARIN assignment contacts to a single ARIN handle, instead of ending up with one handle per assignment, often using an address that was never meant to be used for that purpose. > > Removing the requirement for ARIN to validate the downstream assignments is best, if needed let the RIR's be in charge of this, as they know their customer and the circuits the resources are attached to, and are best equipped to keep this part of the database up to date. ARIN resources ar better used elsewhere. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > _______________________________________________ > 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 hostmaster at uneedus.com Wed May 10 13:49:11 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 10 May 2017 13:49:11 -0400 (EDT) Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> Message-ID: I am opposed to this as well, unless the resources are in fact revoked and reassigned, which in fact, as to legacy resources is never going to happen. While strictly speaking ARIN does not "have" to provide the reverse records, the legacy holders could argue in court that the service was always provided free from the beginning under USG contract and must be centrally done in order to work, and asking that ARIN be ordered to continue to provide rDNS or turn the records back over to the USG so the legacy holder can continue to receive rDNS. Im sure ARIN does not want to get into a cost argument over providing a few PTR records, and the risk of an adverse Court decision. I strongly suspect the real reason the contacts are not being updated is because of ARIN trying to use anything as a stick to force the party to sign an RSA. If the portion permitting the update of POC's without an RSA is adopted, my guess is a lot of those contacts will update to prevent hijacking. The Legacy issue will take care of itself when IPv6 becomes the primary protocol. Some day IPv4 will no longer be routed on the public internet, but I strongly suspect that will be a long time from now. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 10 May 2017, David Huberman wrote: > I really appreciate your email and your thoughts, thank you. Do you have an opinion on the proposal's requirement to remove rDNS delegation records when POCs go unresponsive? As an advisory council member, I really want to hear many operator views on the rDNS portion. > > Thank you, > David > > Sent from my iPhone > >> On May 10, 2017, at 12:19 PM, hostmaster at uneedus.com wrote: >> >> I did not attend ARIN39, but did watch the video of the discussion regarding this Draft Policy. I have looked thru the archives, and have not seen any previous discussion of 2017-3 since its announcement, thus I start the discussion on the list. >> >> I am in favor of the policy changes, except for 3.6.7, which would remove non responsive contacts from the database. While I have no issue with marking any set of contacts as non-responsive, actually removing the last known contact is wrong. While the information may be stale, and the record will state this fact, it still provides an important clue if an investigation regarding that record needs to be taken due to law enforcement needs or other vital purposes. Therefore, until a POC is replaced with another known good POC for that resource or the resource is otherwise revoked, I think the old data should remain for every resource. In fact, until the resource is reassigned to a new holder, there may be good reason to leave it with a notation it has been revoked, giving LIRs a easy way to verify the truth of what might be a forged LOA for the resource. >> >> The most important change in this proposal is allowing legacy contacts to be updated without the signing of an RSA. Of course many at ARIN cannot understand why legacy holders are not rushing to sign, but looking at it from the other side, I fully understand why the lawyers for such firms will not allow it. Please change policy to allow these POCs to update their information. Overall, this will be the best decision. >> >> Of course with IPv6 resources, we are starting with a clean slate and even legacy IPv4 holders require a RSA for these resources. However, on the other side of the coin, because of the larger default blocks allocated, it might be years, or even decades until they return for more resources, making it even more likely than now for POC's to go stale. Since the billing contact is often different than the other network POC's, that does not help in keeping the other POC's current. >> >> During the discussion, a major worldwide content management firm disagreed regarding removal of notification to downstream assignment contacts who have no relationship to ARIN. He found that this is often the only way he discovers POC records created by his many upstream ISP's around the world. >> >> Of course this is only a symptom of what is the TRUE issue, which is allowing the adding of POC records by upstream ISP's for assignments that must be registered at ARIN without first obtaining affirmative consent of the contacts who are added. This is also why the spam laws might be said to apply, since these contacts never gave their consent. Changing the proceedure to require the POC accept before permitting the record to be added is best practice. Of course such contacts need to be able to edit their own POC record, even if there is no contract with ARIN. I understand is an operational issue, not a policy issue. This would also allow the contact to steer all such ARIN assignment contacts to a single ARIN handle, instead of ending up with one handle per assignment, often using an address that was never meant to be used for that purpose. >> >> Removing the requirement for ARIN to validate the downstream assignments is best, if needed let the RIR's be in charge of this, as they know their customer and the circuits the resources are attached to, and are best equipped to keep this part of the database up to date. ARIN resources ar better used elsewhere. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> _______________________________________________ >> 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 Wed May 10 14:34:38 2017 From: john at egh.com (John Santos) Date: Wed, 10 May 2017 14:34:38 -0400 Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> Message-ID: <92132621-af7c-b74b-828d-f606032a7948@egh.com> I'm a little confused by this because my company is a legacy holder and I'm certain I've updated our POC information several times in the past. (At least once because the phone company changed our area code, once because the Post Office changed our ZIP code, and one of our original POCs retired and I changed our company's administrative POC as a result.) I've also changed our rDNS server addresses several times over the years. If it makes any difference, I have been responding to the annual "please validate your POC information" email from ARIN. Am I currently prohibited from making changes, or has maintaining the POC information been sufficient to retain my right to update our records? -- John On 5/10/2017 1:49 PM, hostmaster at uneedus.com wrote: > I am opposed to this as well, unless the resources are in fact revoked > and reassigned, which in fact, as to legacy resources is never going > to happen. > > While strictly speaking ARIN does not "have" to provide the reverse > records, the legacy holders could argue in court that the service was > always provided free from the beginning under USG contract and must be > centrally done in order to work, and asking that ARIN be ordered to > continue to provide rDNS or turn the records back over to the USG so > the legacy holder can continue to receive rDNS. Im sure ARIN does not > want to get into a cost argument over providing a few PTR records, and > the risk of an adverse Court decision. > > I strongly suspect the real reason the contacts are not being updated > is because of ARIN trying to use anything as a stick to force the > party to sign an RSA. If the portion permitting the update of POC's > without an RSA is adopted, my guess is a lot of those contacts will > update to prevent hijacking. > > The Legacy issue will take care of itself when IPv6 becomes the > primary protocol. Some day IPv4 will no longer be routed on the > public internet, but I strongly suspect that will be a long time from > now. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Wed, 10 May 2017, David Huberman wrote: > >> I really appreciate your email and your thoughts, thank you. Do you >> have an opinion on the proposal's requirement to remove rDNS >> delegation records when POCs go unresponsive? As an advisory council >> member, I really want to hear many operator views on the rDNS portion. >> >> Thank you, >> David >> >> Sent from my iPhone >> >>> On May 10, 2017, at 12:19 PM, hostmaster at uneedus.com wrote: >>> >>> I did not attend ARIN39, but did watch the video of the discussion >>> regarding this Draft Policy. I have looked thru the archives, and >>> have not seen any previous discussion of 2017-3 since its >>> announcement, thus I start the discussion on the list. >>> >>> I am in favor of the policy changes, except for 3.6.7, which would >>> remove non responsive contacts from the database. While I have no >>> issue with marking any set of contacts as non-responsive, actually >>> removing the last known contact is wrong. While the information may >>> be stale, and the record will state this fact, it still provides an >>> important clue if an investigation regarding that record needs to be >>> taken due to law enforcement needs or other vital purposes. >>> Therefore, until a POC is replaced with another known good POC for >>> that resource or the resource is otherwise revoked, I think the old >>> data should remain for every resource. In fact, until the resource >>> is reassigned to a new holder, there may be good reason to leave it >>> with a notation it has been revoked, giving LIRs a easy way to >>> verify the truth of what might be a forged LOA for the resource. >>> >>> The most important change in this proposal is allowing legacy >>> contacts to be updated without the signing of an RSA. Of course >>> many at ARIN cannot understand why legacy holders are not rushing to >>> sign, but looking at it from the other side, I fully understand why >>> the lawyers for such firms will not allow it. Please change policy >>> to allow these POCs to update their information. Overall, this will >>> be the best decision. >>> >>> Of course with IPv6 resources, we are starting with a clean slate >>> and even legacy IPv4 holders require a RSA for these resources. >>> However, on the other side of the coin, because of the larger >>> default blocks allocated, it might be years, or even decades until >>> they return for more resources, making it even more likely than now >>> for POC's to go stale. Since the billing contact is often different >>> than the other network POC's, that does not help in keeping the >>> other POC's current. >>> >>> During the discussion, a major worldwide content management firm >>> disagreed regarding removal of notification to downstream assignment >>> contacts who have no relationship to ARIN. He found that this is >>> often the only way he discovers POC records created by his many >>> upstream ISP's around the world. >>> >>> Of course this is only a symptom of what is the TRUE issue, which is >>> allowing the adding of POC records by upstream ISP's for assignments >>> that must be registered at ARIN without first obtaining affirmative >>> consent of the contacts who are added. This is also why the spam >>> laws might be said to apply, since these contacts never gave their >>> consent. Changing the proceedure to require the POC accept before >>> permitting the record to be added is best practice. Of course such >>> contacts need to be able to edit their own POC record, even if there >>> is no contract with ARIN. I understand is an operational issue, not >>> a policy issue. This would also allow the contact to steer all such >>> ARIN assignment contacts to a single ARIN handle, instead of ending >>> up with one handle per assignment, often using an address that was >>> never meant to be used for that purpose. >>> >>> Removing the requirement for ARIN to validate the downstream >>> assignments is best, if needed let the RIR's be in charge of this, >>> as they know their customer and the circuits the resources are >>> attached to, and are best equipped to keep this part of the database >>> up to date. ARIN resources ar better used elsewhere. >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jcurran at arin.net Wed May 10 15:18:53 2017 From: jcurran at arin.net (John Curran) Date: Wed, 10 May 2017 19:18:53 +0000 Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: <92132621-af7c-b74b-828d-f606032a7948@egh.com> References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> <92132621-af7c-b74b-828d-f606032a7948@egh.com> Message-ID: <7DCFE545-E93D-4804-88C5-7FCFB45704AB@arin.net> On 10 May 2017, at 2:34 PM, John Santos > wrote: ... I'm a little confused by this because my company is a legacy holder and I'm certain I've updated our POC information several times in the past. (At least once because the phone company changed our area code, once because the Post Office changed our ZIP code, and one of our original POCs retired and I changed our company's administrative POC as a result.) I've also changed our rDNS server addresses several times over the years. If it makes any difference, I have been responding to the annual "please validate your POC information" email from ARIN. Am I currently prohibited from making changes, or has maintaining the POC information been sufficient to retain my right to update our records? John - It?s a perfectly reasonable question (as there is quite a bit of misinformation out there?) At ARIN?s formation, the Board of Trustees decided that ARIN would provide registration services for these legacy number resources without requiring legacy resource holders to enter into a registration services agreement or pay any fees. All legacy number resource holders are provided these traditional registry services (including the ability to update their information in the ARIN registry) but also have the option to enter into an agreement and pay standard fees if they wish additional services or to formalize their contractual relationship with ARIN. Please refer to for details. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed May 10 15:26:45 2017 From: jcurran at arin.net (John Curran) Date: Wed, 10 May 2017 19:26:45 +0000 Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> Message-ID: <9E5DB15E-308F-4233-8FF7-DC544133298E@arin.net> On 10 May 2017, at 12:19 PM, hostmaster at uneedus.com wrote: The most important change in this proposal is allowing legacy contacts to be updated without the signing of an RSA. Mr. Erdmann - Your assertion to the effect that legacy contacts cannot be updated without signing of an RSA is factually incorrect. Legacy resource holders may update their registration information with entry into any agreement with ARIN, and that has always been the case. Perhaps you are thinking about transfers to another party? (ARIN does insist that the updates to the registry by done in accordance with policy developed by this community, including and specifically in regard to transfers of number resources to others.) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Wed May 10 15:28:01 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 10 May 2017 15:28:01 -0400 (EDT) Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: <7DCFE545-E93D-4804-88C5-7FCFB45704AB@arin.net> References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> <92132621-af7c-b74b-828d-f606032a7948@egh.com> <7DCFE545-E93D-4804-88C5-7FCFB45704AB@arin.net> Message-ID: So in effect, all the proposed 3.6.4 does is to formalize what is the current practice of allowing the change. Thus, there should be no problems with the change. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 10 May 2017, John Curran wrote: > On 10 May 2017, at 2:34 PM, John Santos > wrote: > ... > I'm a little confused by this because my company is a legacy holder and I'm certain I've updated our POC information several times in the past. (At least once because the phone company changed our area code, once because the Post Office changed our ZIP code, and one of our original POCs retired and I changed our company's administrative POC as a result.) I've also changed our rDNS server addresses several times over the years. If it makes any difference, I have been responding to the annual "please validate your POC information" email from ARIN. > > Am I currently prohibited from making changes, or has maintaining the POC information been sufficient to retain my right to update our records? > > John - > > It???s a perfectly reasonable question (as there is quite a bit of misinformation out there???) > > At ARIN???s formation, the Board of Trustees decided that ARIN would provide registration > services for these legacy number resources without requiring legacy resource holders > to enter into a registration services agreement or pay any fees. > > All legacy number resource holders are provided these traditional registry services > (including the ability to update their information in the ARIN registry) but also have > the option to enter into an agreement and pay standard fees if they wish additional > services or to formalize their contractual relationship with ARIN. > > Please refer to for details. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > From hostmaster at uneedus.com Wed May 10 17:57:14 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 10 May 2017 17:57:14 -0400 (EDT) Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> <92132621-af7c-b74b-828d-f606032a7948@egh.com> <7DCFE545-E93D-4804-88C5-7FCFB45704AB@arin.net> Message-ID: Just as a point of information, can someone from ARIN tell us under what conditions (if any) is the POC or the rDNS pointers removed under the current policy? I was doing a bit of looking, and I assume that in any case this policy can only affect legacy class B and C holders, as it appears that PTR records for class A legacy holders do not pass ARIN at any point in the lookup chain, instead being hosted by IAB/ICANN/IANA at the /8 level, making it impossible for the PTR records to be removed by ARIN. Also John Curran was on earlier and said that legacy holders still receive rDNS and are permitted to update their POC's. So what is the story? What subset (if any) of legacy POC's cannot currently change their info, and what triggers that status? Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 10 May 2017, Chris James wrote: > Unless reasonable efforts are made to contact the POC, and this includes > researching and contacting the organization along with every possibly > department, identifying clearly the reason for the call, and actually > trying to update the POC, I fully entirely 100% disagree with discontinuing > rDNS services. > > Image the negative affect to a small ISP who purchases a unit of a major > corporation, somehow the transfer is not done properly, something is not > updated properly, and suddenly every customer of that small ISP who does > not realize they missed updating the POC on a /18 and now a few hundred > small businesses are screwed? > > Image the reverse situation. A major corporation buys a small ISP, I know > we care less and less about the negative impact of policy on ma bell, but > how many innocent users will not receive email, how many inexperienced > users cannot access their own regional bank due to SSL issues thanks to an > arbitrary removal of a few pointers that cost absolutely nothing to keep up? > > I wholly disagree with policy that has the potential to negatively impact > innocent or otherwise inexperienced users based on the unwillingness of an > actual human person to do minor due diligence. If this is too costly an > endeavor for ARIN, scrap the policy altogether. > > Am I reading too far into this or is this outcome entirely impossible? > > > > *Chris James* > > > [image: Datacate] > > > t. 916-526-0737 ext 1002 > e. chris at datacate.com > a. 2999 Gold Canal Dr., Rancho Cordova, CA 95670 > w. https://www.datacate.net > *__________________________________________* > > On Wed, May 10, 2017 at 12:28 PM, wrote: > >> So in effect, all the proposed 3.6.4 does is to formalize what is the >> current practice of allowing the change. Thus, there should be no problems >> with the change. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> On Wed, 10 May 2017, John Curran wrote: >> >> On 10 May 2017, at 2:34 PM, John Santos > >>> wrote: >>> ... >>> I'm a little confused by this because my company is a legacy holder and >>> I'm certain I've updated our POC information several times in the past. >>> (At least once because the phone company changed our area code, once >>> because the Post Office changed our ZIP code, and one of our original POCs >>> retired and I changed our company's administrative POC as a result.) I've >>> also changed our rDNS server addresses several times over the years. If it >>> makes any difference, I have been responding to the annual "please validate >>> your POC information" email from ARIN. >>> >>> Am I currently prohibited from making changes, or has maintaining the POC >>> information been sufficient to retain my right to update our records? >>> >>> John - >>> >>> It???s a perfectly reasonable question (as there is quite a bit of >>> misinformation out there???) >>> >>> At ARIN???s formation, the Board of Trustees decided that ARIN would >>> provide registration >>> services for these legacy number resources without requiring legacy >>> resource holders >>> to enter into a registration services agreement or pay any fees. >>> >>> All legacy number resource holders are provided these traditional >>> registry services >>> (including the ability to update their information in the ARIN registry) >>> but also have >>> the option to enter into an agreement and pay standard fees if they wish >>> additional >>> services or to formalize their contractual relationship with ARIN. >>> >>> Please refer to >>> for details. >>> >>> Thanks! >>> /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. >> > > -- > This e-mail message may contain confidential or legally privileged > information and is intended only for the use of the intended recipient(s). > Any unauthorized disclosure, dissemination, distribution, copying or the > taking of any action in reliance on the information herein is prohibited. > E-mails are not secure and cannot be guaranteed to be error free as they > can be intercepted, amended, or contain viruses. Anyone who communicates > with us by e-mail is deemed to have accepted these risks. This company is > not responsible for errors or omissions in this message and denies any > responsibility for any damage arising from the use of e-mail. Any opinion > and other statement contained in this message and any attachment are solely > those of the author and do not necessarily represent those of the company. > From jcurran at arin.net Wed May 10 20:17:14 2017 From: jcurran at arin.net (John Curran) Date: Thu, 11 May 2017 00:17:14 +0000 Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> <92132621-af7c-b74b-828d-f606032a7948@egh.com> <7DCFE545-E93D-4804-88C5-7FCFB45704AB@arin.net> Message-ID: <709EF30F-FA42-4ABE-836B-BFAB0FF9546F@arin.net> On 10 May 2017, at 5:57 PM, hostmaster at uneedus.com wrote: > > Just as a point of information, can someone from ARIN tell us under what conditions (if any) is the POC or the rDNS pointers removed under the current policy? When the resources are reclaimed/returned/returned to ARIN, the number resources are updated in the registry to point to ARIN, including POC and reverse DNS pointers. Once reissued, they are changed once again (as it done with any issuance) to point to the new resource holder. Thanks, /John John Curran President and CEO ARIN From narten at us.ibm.com Fri May 12 00:53:22 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 12 May 2017 00:53:22 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201705120453.v4C4rM1i032704@rotala.raleigh.ibm.com> Total of 23 messages in the last 7 days. script run at: Fri May 12 00:53:17 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 21.74% | 5 | 33.88% | 123801 | jschiller at google.com 30.43% | 7 | 20.88% | 76303 | jcurran at arin.net 17.39% | 4 | 11.67% | 42620 | hostmaster at uneedus.com 8.70% | 2 | 17.09% | 62429 | mike at iptrading.com 4.35% | 1 | 4.78% | 17474 | austin.murkland at qscend.com 4.35% | 1 | 3.40% | 12439 | john at egh.com 4.35% | 1 | 3.24% | 11852 | scottleibrand at gmail.com 4.35% | 1 | 2.80% | 10214 | daveid at panix.com 4.35% | 1 | 2.25% | 8227 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 23 |100.00% | 365359 | Total From rudi.daniel at gmail.com Sun May 14 12:36:06 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sun, 14 May 2017 12:36:06 -0400 Subject: [arin-ppml] ARIN-PPML 2027-3 In-Reply-To: References: Message-ID: Support much if this proposal, but agree with John re: removal of non responsive contacts from the database. I think removal may create a worse condition ..at least, there is data present, albeit unresponsive..but still a kickoff point for further investigation. I don't know if there needs to be a different consideration for non responsive legacy holders(?) If you have not signed an rsa and still have unresponsive poc, my thinking is that staff should regard this as priority conditions for investigating(?) RD -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Tue May 16 13:48:12 2017 From: jschiller at google.com (Jason Schiller) Date: Tue, 16 May 2017 13:48:12 -0400 Subject: [arin-ppml] ARIN-PPML 2027-3 In-Reply-To: References: Message-ID: How much IT effort would it be to send a $0 bill to legacy holders, and let they either make a $0 payment thought the web site, or include some text on the $0 dollar bill saying click this to acknowledge receipt of this non-bill? ___Jason On Sun, May 14, 2017 at 12:36 PM, Rudolph Daniel wrote: > Support much if this proposal, but agree with John re: removal of non > responsive contacts from the database. I think removal may create a worse > condition ..at least, there is data present, albeit unresponsive..but still > a kickoff point for further investigation. > I don't know if there needs to be a different consideration for non > responsive legacy holders(?) > If you have not signed an rsa and still have unresponsive poc, my thinking > is that staff should regard this as priority conditions for investigating(?) > RD > > _______________________________________________ > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed May 17 08:22:37 2017 From: jcurran at arin.net (John Curran) Date: Wed, 17 May 2017 12:22:37 +0000 Subject: [arin-ppml] ARIN-PPML 2027-3 In-Reply-To: References: Message-ID: On 16 May 2017, at 1:48 PM, Jason Schiller wrote: > > How much IT effort would it be to send a $0 bill to legacy holders, > and let they either make a $0 payment thought the web site, > or include some text on the $0 dollar bill saying click this to > acknowledge receipt of this non-bill? Jason - What would be the purpose of sending a $0 invoice, and what action do you propose that ARIN take if no acknowledgement is received? (Note that some organizations consider a $0 invoice to be equivalent of of an acknowledgement of no outstanding balance and might set aside on the presumption of "no action required?...) /John John Curran President and CEO ARIN From narten at us.ibm.com Fri May 19 00:53:22 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 19 May 2017 00:53:22 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201705190453.v4J4rMYt027305@rotala.raleigh.ibm.com> Total of 4 messages in the last 7 days. script run at: Fri May 19 00:53:16 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 1 | 32.16% | 12774 | jschiller at google.com 25.00% | 1 | 24.91% | 9892 | rudi.daniel at gmail.com 25.00% | 1 | 21.57% | 8566 | narten at us.ibm.com 25.00% | 1 | 21.36% | 8483 | jcurran at arin.net --------+------+--------+----------+------------------------ 100.00% | 4 |100.00% | 39715 | Total From info at arin.net Tue May 23 14:25:47 2017 From: info at arin.net (ARIN) Date: Tue, 23 May 2017 14:25:47 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - May 2017 Message-ID: <59247EAB.8040700@arin.net> In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 18 May 2017. The AC has recommended the following Recommended Draft Policies to the Board of Trustees for adoption: * ARIN-2016-3: Alternative Simplified Criteria for Justifying Small IPv4 Transfers * ARIN-2016-9: Streamline Merger & Acquisition Transfers The AC has advanced the following Proposal to Draft Policy status (will be posted for discussion): * ARIN-prop-240: Equalization of Assignment Registration requirements between IPv4 and IPv6 The AC advances Proposals to Draft Policy status once they are found to be within the scope of the PDP, and contain a clear problem statement and suggested changes to Internet number resource policy text. The AC remanded the following Proposal back to its originator: * ARIN-prop-235: Clarify Generic References to "IP Addresses" in NRPM Policy Proposals that are determined by the AC to lack clarity are remanded back to the originator. The proposal originator revises the Policy Proposal based on the feedback received, and again offers the revised Policy Proposal for evaluation by the AC. Remanded Policy Proposals that are not revised by the originator within 60 days are deemed abandoned. The AC is continuing to work on: * Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers * Draft Policy ARIN-2017-2: Removal of Community Networks * Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The PDP 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, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From info at arin.net Tue May 23 14:35:49 2017 From: info at arin.net (ARIN) Date: Tue, 23 May 2017 14:35:49 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Message-ID: <59248105.8040703@arin.net> On 18 May 2017, the ARIN Advisory Council (AC) accepted "ARIN-prop-240: Equalization of Assignment Registration requirements between IPv4 and IPv6" as a Draft Policy. Draft Policy ARIN-2017-5 is below and can be found at: https://www.arin.net/policy/proposals/2017_5.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP 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, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Problem Statement: Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address or less (CGnat), which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6. Currently, assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4. IPv6 assignments are therefore treated stricter than IPv4 assignments. The policy should treat both protocols the same. A typical ISP serving residential and small business customers with both IPv4 and IPv6 would typically provide the following assignments to each customer site: /32 (one IP) of IPv4 and a /64 (one network) of IPv6. Under the current policy, that small network customer is exempt from registration for their IPv4 assignment, but the ISP would be required to register ALL IPv6 customers, even those of this smallest network size. In actual fact, most ISP's that are providing their customers with a /64 or more of IPv6 space are not in fact registering this fact with ARIN, even though 6.5.5.1 clearly requires this. It is my belief that these residential and small business customers should not require registration if they did not require registration for the same size IPv4 network, including routers with Vlan and other security support. and thus I propose to make the standard for registration only those customers that have more than 16 IPv4 addresses or 16 IPv6 /64 networks. This would treat IPv6 the same as IPv4. Policy statement: Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to "more than a /28". Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to "more than a /60". Comments: Timetable for implementation: Policy should be adopted as soon as possible, as the new administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. IPv6 should not be more burdensome than the equivalent IPv4 network size. Anything else: The specific sizes chosen set the point of registration for each site to more than 16 networks or addresses, so that those with 16 or less networks (IPv6 /60) or addresses (IPv4 /28) have no registration requirement. This change will result in both protocols being treated exactly the same, and removes residential and small business accounts from any registration requirement with ARIN, and the burden that will create for all ISP's. There are those that might argue that a residental customer will never have a need for more than a /64 of IPv6. Clearly this is false in an IOT and/or wireless world, as many routers already provide a separate address range for wired vs wireless to prevent wired hacking via the wireless space, and also may provide a guest wireless SSID apart from the one provided to the regular users of that same network. Such separation in the IPv4 world is currently done in RFC1918 space using NAT. In IPv6, the equivalent must be done with different /64 blocks. Since good security practices require use at least 2 /64 blocks for wireless and/or IOT isolation, this would require a minimum of a /60 of IPv6 space or up to 16 networks or vlans, an amount that is consistent with a residential or small business network. This type network does not trigger registration under the current IPv4 policy, and its equal should not trigger registration with ARIN based on the current IPv6 policy as is currently the case, and thus, this policy needs to be changed. From bill at herrin.us Tue May 23 15:02:24 2017 From: bill at herrin.us (William Herrin) Date: Tue, 23 May 2017 15:02:24 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <59248105.8040703@arin.net> References: <59248105.8040703@arin.net> Message-ID: On Tue, May 23, 2017 at 2:35 PM, ARIN wrote: > Draft Policy ARIN-2017-5: Equalization of Assignment Registration > requirements between IPv4 and IPv6 > > Policy statement: > > Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to > "more than a /28". > Hello, In my opinion... Leave /29 alone or change it to "more than a single IP address." In these days of IPv4 shortage, substantial networks sit behind small blocks of public addresses. These networks should be documented with reachable POCs lest the anti-spam/virus/malware folks slam down /24 filters for lack of information about how misbehaving networks are partitioned. > Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to > "more than a /60". > Change this to "more than a /56." Service providers should NOT be assigning /64's to end users. If you're doing that, you're doing it wrong. An IPv6 customer should be able to have more than one /64 subnet without resorting to NAT so /60 should be the absolute minimum end-user assignment, equivalent for all intents and purposes to an IPv4 /32. If we then want "equivalence" to the /29 policy so that individuals with the minimum and near-minimum assignment do not need to be SWIPed, it makes sense to move the next subnetting level up. In IPv6, assignment is strongly recommended on nibble boundaries, so that means /56. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Tue May 23 15:49:00 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 23 May 2017 12:49:00 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> Message-ID: On Tue, May 23, 2017 at 12:02 PM, William Herrin wrote: > On Tue, May 23, 2017 at 2:35 PM, ARIN wrote: > >> Draft Policy ARIN-2017-5: Equalization of Assignment Registration >> requirements between IPv4 and IPv6 >> >> Policy statement: >> >> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change >> to "more than a /28". >> > > Hello, > > In my opinion... > > Leave /29 alone or change it to "more than a single IP address." In these > days of IPv4 shortage, substantial networks sit behind small blocks of > public addresses. These networks should be documented with reachable POCs > lest the anti-spam/virus/malware folks slam down /24 filters for lack of > information about how misbehaving networks are partitioned. > > >> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to >> "more than a /60". >> > > Change this to "more than a /56." Service providers should NOT be > assigning /64's to end users. If you're doing that, you're doing it wrong. > An IPv6 customer should be able to have more than one /64 subnet without > resorting to NAT so /60 should be the absolute minimum end-user assignment, > equivalent for all intents and purposes to an IPv4 /32. If we then want > "equivalence" to the /29 policy so that individuals with the minimum and > near-minimum assignment do not need to be SWIPed, it makes sense to move > the next subnetting level up. In IPv6, assignment is strongly recommended > on nibble boundaries, so that means /56. > > +1 I believe this policy, as written, is misleadingly titled. I support the intent expressed in the title, and support either the "more than a /60" language or (preferentially) Bill's "more than a /56" language below for equalizing assignment registration requirements between IPv4 and IPv6. However, I definitely do not support also relaxing the "/29 or more" requirement for IPv4 without a significant revision of the problem statement to indicate why such a change is justified, and a retitling of the proposal. And even with those changes, I likely would not support relaxing the "/29 or more" requirement. For context, my employer currently has a large number of /29 networks reassigned from our upstream transit providers (one for each link for unique routing purposes). Those currently are not reassigned to us in whois (in contravention of ARIN policy), but it would be better for us (for geolocation purposes, for example) if they were properly reassigned. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Tue May 23 22:04:56 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Tue, 23 May 2017 22:04:56 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> Message-ID: Hello, The line has to be drawn somewhere, and the idea when I drafted this proposal was that it was wrong to treat IPv6 less favored than IPv6 as is the current case. It also bothered me that the average residential and small business account would have to go thru the SWIP process, just because they want to have a minimum or so assignment of IPv6 space for their network, when this was never a requirement for IPv4. As discussed, a /60 of v6 is much the same as a /32 of v4. I chose 16 addresses/networks as the only reasonable number to make the two protocols equal. As already discussed, 1 network is too small. If the community thinks it is wrong to relax the current IPv4 requirements, I am not opposed to removing 4.2.3.7.1 from the proposal, as long as the community is willing to do something about the "Register every network" problem that is the current policy in v6, and the changes to 6.5.5.1 that I propose. While I suggest that a /60 should not trigger registration, if the community would rather kick that up to a /56, I have no problem with this. This would seem to be the more future proof option. Of course such a change calls for a new title, maybe "New policy for IPv6 Assignment Registration", and cite it as allowing even the small networks with a /32 of IPv4 to obtain a reasonable assignment of IPv6 without registration requirements, as is the current case with IPv4. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 23 May 2017, William Herrin wrote: > On Tue, May 23, 2017 at 2:35 PM, ARIN wrote: > >> Draft Policy ARIN-2017-5: Equalization of Assignment Registration >> requirements between IPv4 and IPv6 >> >> Policy statement: >> >> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to >> "more than a /28". >> > > Hello, > > In my opinion... > > Leave /29 alone or change it to "more than a single IP address." In these > days of IPv4 shortage, substantial networks sit behind small blocks of > public addresses. These networks should be documented with reachable POCs > lest the anti-spam/virus/malware folks slam down /24 filters for lack of > information about how misbehaving networks are partitioned. > > >> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to >> "more than a /60". >> > > Change this to "more than a /56." Service providers should NOT be assigning > /64's to end users. If you're doing that, you're doing it wrong. An IPv6 > customer should be able to have more than one /64 subnet without resorting > to NAT so /60 should be the absolute minimum end-user assignment, > equivalent for all intents and purposes to an IPv4 /32. If we then want > "equivalence" to the /29 policy so that individuals with the minimum and > near-minimum assignment do not need to be SWIPed, it makes sense to move > the next subnetting level up. In IPv6, assignment is strongly recommended > on nibble boundaries, so that means /56. > > Regards, > Bill Herrin > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From chris at semihuman.com Thu May 25 11:25:00 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 25 May 2017 08:25:00 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> Message-ID: I?d support the relaxation of SWIP requirements for IPv6 allocations, but relaxing SWIP requirements for IPv4 does not, in my view, line up with the problem statement as the proposal is written; if the goal is equal treatment, then one should align IPv6 policy to existing v4, not change both. I?d recommend that we limit this proposal to only the 6.5.5.1 change. Thanks, -Chris > On May 23, 2017, at 7:04 PM, hostmaster at uneedus.com wrote: > > Hello, > > The line has to be drawn somewhere, and the idea when I drafted this proposal was that it was wrong to treat IPv6 less favored than IPv6 as is the current case. It also bothered me that the average residential and small business account would have to go thru the SWIP process, just because they want to have a minimum or so assignment of IPv6 space for their network, when this was never a requirement for IPv4. As discussed, a /60 of v6 is much the same as a /32 of v4. > > I chose 16 addresses/networks as the only reasonable number to make the two protocols equal. As already discussed, 1 network is too small. If the community thinks it is wrong to relax the current IPv4 requirements, I am not opposed to removing 4.2.3.7.1 from the proposal, as long as the community is willing to do something about the "Register every network" problem that is the current policy in v6, and the changes to 6.5.5.1 that I propose. > > While I suggest that a /60 should not trigger registration, if the community would rather kick that up to a /56, I have no problem with this. This would seem to be the more future proof option. Of course such a change calls for a new title, maybe "New policy for IPv6 Assignment Registration", and cite it as allowing even the small networks with a /32 of IPv4 to obtain a reasonable assignment of IPv6 without registration requirements, as is the current case with IPv4. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Tue, 23 May 2017, William Herrin wrote: > >> On Tue, May 23, 2017 at 2:35 PM, ARIN wrote: >> >>> Draft Policy ARIN-2017-5: Equalization of Assignment Registration >>> requirements between IPv4 and IPv6 >>> >>> Policy statement: >>> >>> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to >>> "more than a /28". >>> >> >> Hello, >> >> In my opinion... >> >> Leave /29 alone or change it to "more than a single IP address." In these >> days of IPv4 shortage, substantial networks sit behind small blocks of >> public addresses. These networks should be documented with reachable POCs >> lest the anti-spam/virus/malware folks slam down /24 filters for lack of >> information about how misbehaving networks are partitioned. >> >> >>> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to >>> "more than a /60". >>> >> >> Change this to "more than a /56." Service providers should NOT be assigning >> /64's to end users. If you're doing that, you're doing it wrong. An IPv6 >> customer should be able to have more than one /64 subnet without resorting >> to NAT so /60 should be the absolute minimum end-user assignment, >> equivalent for all intents and purposes to an IPv4 /32. If we then want >> "equivalence" to the /29 policy so that individuals with the minimum and >> near-minimum assignment do not need to be SWIPed, it makes sense to move >> the next subnetting level up. In IPv6, assignment is strongly recommended >> on nibble boundaries, so that means /56. >> >> Regards, >> Bill Herrin >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> > _______________________________________________ > 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 jschiller at google.com Thu May 25 13:53:53 2017 From: jschiller at google.com (Jason Schiller) Date: Thu, 25 May 2017 13:53:53 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> Message-ID: I don't support a relaxation of SWIP requirements for IPv4. I do support updating the language for IPv4 for clarity (if that is useful). current IPv4 language: /29 or more possibly re-write for clarity: more than a /30. As far as IPv6 goes, there are some who recommend a /64 for point-to-point. One might argue that in the context of p-t-p an IPv4 /30 maps to a /64. I could certainly get behind SWIP requirements for "more than a /64" on these grounds. Please make the requirement to SWIP be on a nibble boundary. Nibbles being nice things, one could argue that end users are likely to get a /64 or the next size up which is a /60. If you want to catch all customers in the smallest size, you might make the boundary at "more than a /61" The next size up on the nibble boundary is a /56 putting the boundary at "more than a /57" Generally speaking any network that is sufficiently large to require subnetting, should have sufficient clue to support SWIP. Based on this reasoning "more than a /64" seems like an equable place to draw the line. Even "more than a /61" seems reasonable, as blocks are likely going to be assigned on nibbles. My next preferred choice would be "more than a /57" Also don't forget that residential users can opt out of publicly providing information. ___Jason On Tue, May 23, 2017 at 10:04 PM, wrote: > Hello, > > The line has to be drawn somewhere, and the idea when I drafted this > proposal was that it was wrong to treat IPv6 less favored than IPv6 as is > the current case. It also bothered me that the average residential and > small business account would have to go thru the SWIP process, just because > they want to have a minimum or so assignment of IPv6 space for their > network, when this was never a requirement for IPv4. As discussed, a /60 > of v6 is much the same as a /32 of v4. > > I chose 16 addresses/networks as the only reasonable number to make the > two protocols equal. As already discussed, 1 network is too small. If the > community thinks it is wrong to relax the current IPv4 requirements, I am > not opposed to removing 4.2.3.7.1 from the proposal, as long as the > community is willing to do something about the "Register every network" > problem that is the current policy in v6, and the changes to 6.5.5.1 that I > propose. > > While I suggest that a /60 should not trigger registration, if the > community would rather kick that up to a /56, I have no problem with this. > This would seem to be the more future proof option. Of course such a change > calls for a new title, maybe "New policy for IPv6 Assignment Registration", > and cite it as allowing even the small networks with a /32 of IPv4 to > obtain a reasonable assignment of IPv6 without registration requirements, > as is the current case with IPv4. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > On Tue, 23 May 2017, William Herrin wrote: > > On Tue, May 23, 2017 at 2:35 PM, ARIN wrote: >> >> Draft Policy ARIN-2017-5: Equalization of Assignment Registration >>> requirements between IPv4 and IPv6 >>> >>> Policy statement: >>> >>> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change >>> to >>> "more than a /28". >>> >>> >> Hello, >> >> In my opinion... >> >> Leave /29 alone or change it to "more than a single IP address." In these >> days of IPv4 shortage, substantial networks sit behind small blocks of >> public addresses. These networks should be documented with reachable POCs >> lest the anti-spam/virus/malware folks slam down /24 filters for lack of >> information about how misbehaving networks are partitioned. >> >> >> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to >>> "more than a /60". >>> >>> >> Change this to "more than a /56." Service providers should NOT be >> assigning >> /64's to end users. If you're doing that, you're doing it wrong. An IPv6 >> customer should be able to have more than one /64 subnet without resorting >> to NAT so /60 should be the absolute minimum end-user assignment, >> equivalent for all intents and purposes to an IPv4 /32. If we then want >> "equivalence" to the /29 policy so that individuals with the minimum and >> near-minimum assignment do not need to be SWIPed, it makes sense to move >> the next subnetting level up. In IPv6, assignment is strongly recommended >> on nibble boundaries, so that means /56. >> >> Regards, >> Bill Herrin >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> >> _______________________________________________ > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Thu May 25 14:08:08 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 25 May 2017 11:08:08 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <59248105.8040703@arin.net> References: <59248105.8040703@arin.net> Message-ID: <22e8fa52-56a6-a38e-b81f-daa9ecb5e123@rollernet.us> On 5/23/17 11:35, ARIN wrote: > Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change > to "more than a /28". I do not support changing the threshold for IPv4, therefore I oppose this policy. ~Seth From rfg at tristatelogic.com Thu May 25 14:38:03 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 25 May 2017 11:38:03 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) Message-ID: <62130.1495737483@segfault.tristatelogic.com> Greetings all, My apologies for barging in to the middle of a serious dicsussion about an actual draft ARIN proposal, just to ask a naive question, but I really did want to get some help understanding this. And as long as it is being discussed anyway... I only watch the traffic on this mailing list out of the corner of one eye, while I'm actually working on other, and mostly unrelated things, but I do believe that I've seen more than one reference here recently to some purported/alleged requirement that each allocation of ARIN IPv4 space that is sub-assigned to a given customer is supposedly required to have its own "SWIP" which I assume means that it must also get its own record in the ARIN data base, yes? If true, this comes as a big shock and surprise to me, and I'd appreciate someone giving me the exact citation for this rule, so that I can properly cite it to others. Anyway, assuming that such a rule does exist, it would seem to be, as the old saying goes, a rule which is "more honored in the breach than in the observance". I -daily- see cases where sub-parts of some IPv4 allocation that was made to some provider have quite clearly been given over to this spammer or to that spammer, and I am likewise daily frustrated at not being able to gather more information, e.g. from ARIN WHOIS, or even, in general, from Rwhois services, about the identities of these spammers. So, my final question: Assuming that such a "rule" does exist, i.e. one requiring sub-allocations of /29 or larger to be documented in the ARIN WHOIS data base, then what exactly is the penality for a provider who does not adhere to this rule? Are they sent to bed without dessert? Thank you all for your indulgence of my naive questions. Regards, rfg From sethm at rollernet.us Thu May 25 14:47:34 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 25 May 2017 11:47:34 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <62130.1495737483@segfault.tristatelogic.com> References: <62130.1495737483@segfault.tristatelogic.com> Message-ID: <8f79ce56-9a9a-18a8-94df-d29c21563648@rollernet.us> On 5/25/17 11:38, Ronald F. Guilmette wrote: > If true, this comes as a big shock and surprise to me, and I'd appreciate > someone giving me the exact citation for this rule, so that I can properly > cite it to others. NRPM section 4.2.3.7 ~Seth From rfg at tristatelogic.com Thu May 25 15:19:37 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 25 May 2017 12:19:37 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <8f79ce56-9a9a-18a8-94df-d29c21563648@rollernet.us> Message-ID: <62299.1495739977@segfault.tristatelogic.com> In message <8f79ce56-9a9a-18a8-94df-d29c21563648 at rollernet.us>, Seth Mattinen wrote: >On 5/25/17 11:38, Ronald F. Guilmette wrote: >> If true, this comes as a big shock and surprise to me, and I'd appreciate >> someone giving me the exact citation for this rule, so that I can properly >> cite it to others. > > >NRPM section 4.2.3.7 Thank you for the refernece. I've just now perused it, and it is most enlightening. May I safely assume that when, on a nearly daily basis, I encounter unambiguous violations of the above cited ARIN NRPM section, that I should immediately bring all such violations to the attention of The Internet Police? Reading over NRPM 4.2.3.7, I am also left just slightly unclear on a couple of small but important points that relate directly to situations that I seem to come upon with great frequency in my daily research. Specifically, where may I find a formal definition for the term "Residential Customer"? Given that every legal entity, human or otherwise, "resides" somewhere, even if only within the 4x4 inch confines of a rented P.O. box, it would seem arguable that every legal entity on the planet could, depending on one's definition, qualify as a "Residential Customer". (And on a related note, I cannot help by wonder aloud if there is any limit to the size of allocations made to "Residential Customers". May a "Residential Customer" be assigned an IPv4 /16?) Second... and I don't think that I'm the first to ask about this... may an ARIN member that has received a direct allocation satisfy the edicts of NRPM 4.2.3.7 by creating SWIPs or Rwhois records which make reference to non-person legal entities which demonstratably no longer exist, in a legal sense? Again, I thank everyone for your indulgence while I try to understand this very interesting policy (NRPM 4.2.3.7). Regards, rfg From adudek16 at gmail.com Thu May 25 23:33:10 2017 From: adudek16 at gmail.com (Aaron Dudek) Date: Thu, 25 May 2017 23:33:10 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> Message-ID: I don't believe a /64 is recommended for a p2p anymore. Rfc 6164 On Thursday, May 25, 2017, Jason Schiller wrote: > I don't support a relaxation of SWIP requirements for IPv4. > > I do support updating the language for IPv4 for clarity (if that is > useful). > current IPv4 language: /29 or more > > possibly re-write for clarity: more than a /30. > > > As far as IPv6 goes, there are some who recommend a /64 for point-to-point. > One might argue that in the context of p-t-p an IPv4 /30 maps to a /64. > > I could certainly get behind SWIP requirements for "more than a /64" on > these grounds. > > Please make the requirement to SWIP be on a nibble boundary. > > > Nibbles being nice things, one could argue that end users are likely to > get a /64 > or the next size up which is a /60. If you want to catch all customers in > the > smallest size, you might make the boundary at "more than a /61" > > The next size up on the nibble boundary is a /56 putting the boundary at > "more than a /57" > > > Generally speaking any network that is sufficiently large to require > subnetting, > should have sufficient clue to support SWIP. Based on this reasoning > "more than > a /64" seems like an equable place to draw the line. Even "more than a > /61" > seems reasonable, as blocks are likely going to be assigned on nibbles. > My next preferred choice would be "more than a /57" > > Also don't forget that residential users can opt out of publicly providing > information. > > ___Jason > > > > > > > > On Tue, May 23, 2017 at 10:04 PM, > wrote: > >> Hello, >> >> The line has to be drawn somewhere, and the idea when I drafted this >> proposal was that it was wrong to treat IPv6 less favored than IPv6 as is >> the current case. It also bothered me that the average residential and >> small business account would have to go thru the SWIP process, just because >> they want to have a minimum or so assignment of IPv6 space for their >> network, when this was never a requirement for IPv4. As discussed, a /60 >> of v6 is much the same as a /32 of v4. >> >> I chose 16 addresses/networks as the only reasonable number to make the >> two protocols equal. As already discussed, 1 network is too small. If the >> community thinks it is wrong to relax the current IPv4 requirements, I am >> not opposed to removing 4.2.3.7.1 from the proposal, as long as the >> community is willing to do something about the "Register every network" >> problem that is the current policy in v6, and the changes to 6.5.5.1 that I >> propose. >> >> While I suggest that a /60 should not trigger registration, if the >> community would rather kick that up to a /56, I have no problem with this. >> This would seem to be the more future proof option. Of course such a change >> calls for a new title, maybe "New policy for IPv6 Assignment Registration", >> and cite it as allowing even the small networks with a /32 of IPv4 to >> obtain a reasonable assignment of IPv6 without registration requirements, >> as is the current case with IPv4. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> >> On Tue, 23 May 2017, William Herrin wrote: >> >> On Tue, May 23, 2017 at 2:35 PM, ARIN >> > wrote: >>> >>> Draft Policy ARIN-2017-5: Equalization of Assignment Registration >>>> requirements between IPv4 and IPv6 >>>> >>>> Policy statement: >>>> >>>> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change >>>> to >>>> "more than a /28". >>>> >>>> >>> Hello, >>> >>> In my opinion... >>> >>> Leave /29 alone or change it to "more than a single IP address." In these >>> days of IPv4 shortage, substantial networks sit behind small blocks of >>> public addresses. These networks should be documented with reachable POCs >>> lest the anti-spam/virus/malware folks slam down /24 filters for lack of >>> information about how misbehaving networks are partitioned. >>> >>> >>> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to >>>> "more than a /60". >>>> >>>> >>> Change this to "more than a /56." Service providers should NOT be >>> assigning >>> /64's to end users. If you're doing that, you're doing it wrong. An IPv6 >>> customer should be able to have more than one /64 subnet without >>> resorting >>> to NAT so /60 should be the absolute minimum end-user assignment, >>> equivalent for all intents and purposes to an IPv4 /32. If we then want >>> "equivalence" to the /29 policy so that individuals with the minimum and >>> near-minimum assignment do not need to be SWIPed, it makes sense to move >>> the next subnetting level up. In IPv6, assignment is strongly recommended >>> on nibble boundaries, so that means /56. >>> >>> Regards, >>> Bill Herrin >>> >>> -- >>> William Herrin ................ herrin at dirtside.com >>> bill at herrin.us >>> >>> Dirtside Systems ......... Web: >>> >>> _______________________________________________ >> 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. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com > |571-266-0006 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri May 26 00:53:22 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 26 May 2017 00:53:22 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201705260453.v4Q4rML2015752@rotala.raleigh.ibm.com> Total of 13 messages in the last 7 days. script run at: Fri May 26 00:53:17 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.38% | 2 | 12.62% | 17548 | info at arin.net 15.38% | 2 | 10.17% | 14138 | rfg at tristatelogic.com 15.38% | 2 | 9.12% | 12679 | sethm at rollernet.us 7.69% | 1 | 15.84% | 22020 | adudek16 at gmail.com 7.69% | 1 | 14.85% | 20639 | jschiller at google.com 7.69% | 1 | 10.11% | 14052 | scottleibrand at gmail.com 7.69% | 1 | 7.76% | 10786 | bill at herrin.us 7.69% | 1 | 7.14% | 9923 | chris at semihuman.com 7.69% | 1 | 6.40% | 8892 | hostmaster at uneedus.com 7.69% | 1 | 6.00% | 8337 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 13 |100.00% | 139014 | Total From hostmaster at uneedus.com Fri May 26 00:22:37 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 26 May 2017 00:22:37 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> Message-ID: RFC 4291, section 2.5.4 provide that the interface ID is /64 for all global unicast addresses, which is the reason that all v6 lan networks are set to /64, and this should include p2p links Network World at the time had quite a discussion about this and RFC 6164. They point out that we have no problems with waste when we use say 5000 addreseses on a /64, but not with using 2 in a point to point link, forgetting that the difference between 5000 and 2 is nothing when there is 18 million trillion addresses on that subnet. It was also pointed out that using a /127 prevented certain attacks, but simply turning off neighbor discovery (the true issue) on these links also has the same effect. Maybe someone should update that RFC. I think the advantages of /64 everywhere I think outweighs the value of using a /127 p2p link. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 25 May 2017, Aaron Dudek wrote: > I don't believe a /64 is recommended for a p2p anymore. Rfc 6164 > > On Thursday, May 25, 2017, Jason Schiller wrote: > >> I don't support a relaxation of SWIP requirements for IPv4. >> >> I do support updating the language for IPv4 for clarity (if that is >> useful). >> current IPv4 language: /29 or more >> >> possibly re-write for clarity: more than a /30. >> >> >> As far as IPv6 goes, there are some who recommend a /64 for point-to-point. >> One might argue that in the context of p-t-p an IPv4 /30 maps to a /64. >> >> I could certainly get behind SWIP requirements for "more than a /64" on >> these grounds. >> >> Please make the requirement to SWIP be on a nibble boundary. >> >> >> Nibbles being nice things, one could argue that end users are likely to >> get a /64 >> or the next size up which is a /60. If you want to catch all customers in >> the >> smallest size, you might make the boundary at "more than a /61" >> >> The next size up on the nibble boundary is a /56 putting the boundary at >> "more than a /57" >> >> >> Generally speaking any network that is sufficiently large to require >> subnetting, >> should have sufficient clue to support SWIP. Based on this reasoning >> "more than >> a /64" seems like an equable place to draw the line. Even "more than a >> /61" >> seems reasonable, as blocks are likely going to be assigned on nibbles. >> My next preferred choice would be "more than a /57" >> >> Also don't forget that residential users can opt out of publicly providing >> information. >> >> ___Jason >> >> >> >> >> >> >> >> On Tue, May 23, 2017 at 10:04 PM, > > wrote: >> >>> Hello, >>> >>> The line has to be drawn somewhere, and the idea when I drafted this >>> proposal was that it was wrong to treat IPv6 less favored than IPv6 as is >>> the current case. It also bothered me that the average residential and >>> small business account would have to go thru the SWIP process, just because >>> they want to have a minimum or so assignment of IPv6 space for their >>> network, when this was never a requirement for IPv4. As discussed, a /60 >>> of v6 is much the same as a /32 of v4. >>> >>> I chose 16 addresses/networks as the only reasonable number to make the >>> two protocols equal. As already discussed, 1 network is too small. If the >>> community thinks it is wrong to relax the current IPv4 requirements, I am >>> not opposed to removing 4.2.3.7.1 from the proposal, as long as the >>> community is willing to do something about the "Register every network" >>> problem that is the current policy in v6, and the changes to 6.5.5.1 that I >>> propose. >>> >>> While I suggest that a /60 should not trigger registration, if the >>> community would rather kick that up to a /56, I have no problem with this. >>> This would seem to be the more future proof option. Of course such a change >>> calls for a new title, maybe "New policy for IPv6 Assignment Registration", >>> and cite it as allowing even the small networks with a /32 of IPv4 to >>> obtain a reasonable assignment of IPv6 without registration requirements, >>> as is the current case with IPv4. >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> >>> On Tue, 23 May 2017, William Herrin wrote: >>> >>> On Tue, May 23, 2017 at 2:35 PM, ARIN >>> > wrote: >>>> >>>> Draft Policy ARIN-2017-5: Equalization of Assignment Registration >>>>> requirements between IPv4 and IPv6 >>>>> >>>>> Policy statement: >>>>> >>>>> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change >>>>> to >>>>> "more than a /28". >>>>> >>>>> >>>> Hello, >>>> >>>> In my opinion... >>>> >>>> Leave /29 alone or change it to "more than a single IP address." In these >>>> days of IPv4 shortage, substantial networks sit behind small blocks of >>>> public addresses. These networks should be documented with reachable POCs >>>> lest the anti-spam/virus/malware folks slam down /24 filters for lack of >>>> information about how misbehaving networks are partitioned. >>>> >>>> >>>> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to >>>>> "more than a /60". >>>>> >>>>> >>>> Change this to "more than a /56." Service providers should NOT be >>>> assigning >>>> /64's to end users. If you're doing that, you're doing it wrong. An IPv6 >>>> customer should be able to have more than one /64 subnet without >>>> resorting >>>> to NAT so /60 should be the absolute minimum end-user assignment, >>>> equivalent for all intents and purposes to an IPv4 /32. If we then want >>>> "equivalence" to the /29 policy so that individuals with the minimum and >>>> near-minimum assignment do not need to be SWIPed, it makes sense to move >>>> the next subnetting level up. In IPv6, assignment is strongly recommended >>>> on nibble boundaries, so that means /56. >>>> >>>> Regards, >>>> Bill Herrin >>>> >>>> -- >>>> William Herrin ................ herrin at dirtside.com >>>> bill at herrin.us >>>> >>>> Dirtside Systems ......... Web: >>>> >>>> _______________________________________________ >>> 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. >>> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com >> |571-266-0006 >> >> > From Hostmaster at uneedus.com Fri May 26 00:02:34 2017 From: Hostmaster at uneedus.com (Hostmaster at uneedus.com) Date: Fri, 26 May 2017 00:02:34 -0400 (EDT) Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <62299.1495739977@segfault.tristatelogic.com> References: <62299.1495739977@segfault.tristatelogic.com> Message-ID: This proposal was intended to try to bring the v4 and v6 world together on the same policy. Because of the nibble boundary rule and rDNS, on the v6 side, there are really only 5 choices in network size: /48, /52, /56, /60 and /64 without having to do non-standard CNAME tricks used when subdividing the rDNS for more than one customer in a /24 of v4. V6 Stated another way: /64 is one network, /60 is 16 networks, and /56 is 256 networks. Since most sane networks want to separate their IOT, Guest and Subscriber devices network from one another, this means that /60 is as small as is reasonable to go, and still maintain parity with the /32 of v4 space used by residential and small business clients and the current and future technology in the v4 world. Some comments clearly state that operators should not be giving out anything less than a /60, which seems to state v6 /60 is the same as v4 /32. The focus of the proposal to me is v6 parity or better. Since current policy seems to have no issue with a blanket policy of a /48 for every site, there should be no issue with a /56 or /60 as far as wastefulness of address space, a more conserving choice. Since 16 seemed like a magic number, I thought the perfect line would be more than 16 networks for v6 or 16 addresses for v4 without knowing the community wants to keep 8 address or more assignment registration for v4. I now realize that there is no case to change this just to acheve absolute parity, and I see nothing wrong with giving v6 a slight advantage. We do need to do something about the current IPv6 policy that requires ALL IPv6 assignments be registered, even those customers with the smallest possible size network of /64. I suggest "More than a /56" is best for 6.5.5.1, and we remove the v4 proposal 4.2.3.7.1, since there appears to be strong agreement to leave the current level of assignment registration for v4. While argument can be made that /60 is enough, the next step up is reasonable at more than /56. What I would like to hear from the community is their input as to where to draw the line for 6.5.5.1. While I proposed both /60 and /64 be exempt from registration, other comments suggest that /56 should as well. Currently a /64 or more (which is ALL IPv6 networks) must be SWIP'ed. Our choices is to leave this requirement alone or: 1) Change to More than a /64, which has the disadvantage of prohibiting any subnetting. 2) Change to More than a /60, which is the current proposal, which will allow up to 16 subnets for IOT/VLAN/other future uses. 3) Change to More than a /56 which will allow 256 networks, and a bit more future proofing, but not so much to be unreasonable. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 25 May 2017, Ronald F. Guilmette wrote: > > In message <8f79ce56-9a9a-18a8-94df-d29c21563648 at rollernet.us>, > Seth Mattinen wrote: > >> On 5/25/17 11:38, Ronald F. Guilmette wrote: >>> If true, this comes as a big shock and surprise to me, and I'd appreciate >>> someone giving me the exact citation for this rule, so that I can properly >>> cite it to others. >> >> >> NRPM section 4.2.3.7 > > Thank you for the refernece. I've just now perused it, and it is most > enlightening. > > May I safely assume that when, on a nearly daily basis, I encounter > unambiguous violations of the above cited ARIN NRPM section, that I > should immediately bring all such violations to the attention of > The Internet Police? > > Reading over NRPM 4.2.3.7, I am also left just slightly unclear on a > couple of small but important points that relate directly to situations > that I seem to come upon with great frequency in my daily research. > > Specifically, where may I find a formal definition for the term > "Residential Customer"? Given that every legal entity, human or > otherwise, "resides" somewhere, even if only within the 4x4 inch > confines of a rented P.O. box, it would seem arguable that every > legal entity on the planet could, depending on one's definition, > qualify as a "Residential Customer". (And on a related note, I > cannot help by wonder aloud if there is any limit to the size of > allocations made to "Residential Customers". May a "Residential > Customer" be assigned an IPv4 /16?) > > Second... and I don't think that I'm the first to ask about this... > may an ARIN member that has received a direct allocation satisfy > the edicts of NRPM 4.2.3.7 by creating SWIPs or Rwhois records which > make reference to non-person legal entities which demonstratably no > longer exist, in a legal sense? > > Again, I thank everyone for your indulgence while I try to understand > this very interesting policy (NRPM 4.2.3.7). > > > Regards, > rfg > _______________________________________________ > 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 ppml at rsuc.gweep.net Fri May 26 15:47:15 2017 From: ppml at rsuc.gweep.net (Joe Provo) Date: Fri, 26 May 2017 15:47:15 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> Message-ID: <20170526194714.GA91009@gweep.net> pardon top-post; on mobile the spec doesn't match operational reality, hence https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/ cheers, Joe On Fri, May 26, 2017 at 12:22:37AM -0400, hostmaster at uneedus.com wrote: > RFC 4291, section 2.5.4 provide that the interface ID is /64 for all > global unicast addresses, which is the reason that all v6 lan networks are > set to /64, and this should include p2p links > > Network World at the time had quite a discussion about this and RFC 6164. > > They point out that we have no problems with waste when we use say 5000 > addreseses on a /64, but not with using 2 in a point to point link, > forgetting that the difference between 5000 and 2 is nothing when there is > 18 million trillion addresses on that subnet. > > It was also pointed out that using a /127 prevented certain attacks, but > simply turning off neighbor discovery (the true issue) on these links also > has the same effect. Maybe someone should update that RFC. I think the > advantages of /64 everywhere I think outweighs the value of using a /127 > p2p link. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Thu, 25 May 2017, Aaron Dudek wrote: > > > I don't believe a /64 is recommended for a p2p anymore. Rfc 6164 > > > > On Thursday, May 25, 2017, Jason Schiller wrote: > > > >> I don't support a relaxation of SWIP requirements for IPv4. > >> > >> I do support updating the language for IPv4 for clarity (if that is > >> useful). > >> current IPv4 language: /29 or more > >> > >> possibly re-write for clarity: more than a /30. > >> > >> > >> As far as IPv6 goes, there are some who recommend a /64 for point-to-point. > >> One might argue that in the context of p-t-p an IPv4 /30 maps to a /64. > >> > >> I could certainly get behind SWIP requirements for "more than a /64" on > >> these grounds. > >> > >> Please make the requirement to SWIP be on a nibble boundary. > >> > >> > >> Nibbles being nice things, one could argue that end users are likely to > >> get a /64 > >> or the next size up which is a /60. If you want to catch all customers in > >> the > >> smallest size, you might make the boundary at "more than a /61" > >> > >> The next size up on the nibble boundary is a /56 putting the boundary at > >> "more than a /57" > >> > >> > >> Generally speaking any network that is sufficiently large to require > >> subnetting, > >> should have sufficient clue to support SWIP. Based on this reasoning > >> "more than > >> a /64" seems like an equable place to draw the line. Even "more than a > >> /61" > >> seems reasonable, as blocks are likely going to be assigned on nibbles. > >> My next preferred choice would be "more than a /57" > >> > >> Also don't forget that residential users can opt out of publicly providing > >> information. > >> > >> ___Jason > >> > >> > >> > >> > >> > >> > >> > >> On Tue, May 23, 2017 at 10:04 PM, >> > wrote: > >> > >>> Hello, > >>> > >>> The line has to be drawn somewhere, and the idea when I drafted this > >>> proposal was that it was wrong to treat IPv6 less favored than IPv6 as is > >>> the current case. It also bothered me that the average residential and > >>> small business account would have to go thru the SWIP process, just because > >>> they want to have a minimum or so assignment of IPv6 space for their > >>> network, when this was never a requirement for IPv4. As discussed, a /60 > >>> of v6 is much the same as a /32 of v4. > >>> > >>> I chose 16 addresses/networks as the only reasonable number to make the > >>> two protocols equal. As already discussed, 1 network is too small. If the > >>> community thinks it is wrong to relax the current IPv4 requirements, I am > >>> not opposed to removing 4.2.3.7.1 from the proposal, as long as the > >>> community is willing to do something about the "Register every network" > >>> problem that is the current policy in v6, and the changes to 6.5.5.1 that I > >>> propose. > >>> > >>> While I suggest that a /60 should not trigger registration, if the > >>> community would rather kick that up to a /56, I have no problem with this. > >>> This would seem to be the more future proof option. Of course such a change > >>> calls for a new title, maybe "New policy for IPv6 Assignment Registration", > >>> and cite it as allowing even the small networks with a /32 of IPv4 to > >>> obtain a reasonable assignment of IPv6 without registration requirements, > >>> as is the current case with IPv4. > >>> > >>> Albert Erdmann > >>> Network Administrator > >>> Paradise On Line Inc. > >>> > >>> > >>> > >>> On Tue, 23 May 2017, William Herrin wrote: > >>> > >>> On Tue, May 23, 2017 at 2:35 PM, ARIN >>>> > wrote: > >>>> > >>>> Draft Policy ARIN-2017-5: Equalization of Assignment Registration > >>>>> requirements between IPv4 and IPv6 > >>>>> > >>>>> Policy statement: > >>>>> > >>>>> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change > >>>>> to > >>>>> "more than a /28". > >>>>> > >>>>> > >>>> Hello, > >>>> > >>>> In my opinion... > >>>> > >>>> Leave /29 alone or change it to "more than a single IP address." In these > >>>> days of IPv4 shortage, substantial networks sit behind small blocks of > >>>> public addresses. These networks should be documented with reachable POCs > >>>> lest the anti-spam/virus/malware folks slam down /24 filters for lack of > >>>> information about how misbehaving networks are partitioned. > >>>> > >>>> > >>>> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to > >>>>> "more than a /60". > >>>>> > >>>>> > >>>> Change this to "more than a /56." Service providers should NOT be > >>>> assigning > >>>> /64's to end users. If you're doing that, you're doing it wrong. An IPv6 > >>>> customer should be able to have more than one /64 subnet without > >>>> resorting > >>>> to NAT so /60 should be the absolute minimum end-user assignment, > >>>> equivalent for all intents and purposes to an IPv4 /32. If we then want > >>>> "equivalence" to the /29 policy so that individuals with the minimum and > >>>> near-minimum assignment do not need to be SWIPed, it makes sense to move > >>>> the next subnetting level up. In IPv6, assignment is strongly recommended > >>>> on nibble boundaries, so that means /56. > >>>> > >>>> Regards, > >>>> Bill Herrin > >>>> > >>>> -- > >>>> William Herrin ................ herrin at dirtside.com > >>>> bill at herrin.us > >>>> > >>>> Dirtside Systems ......... Web: > >>>> > >>>> _______________________________________________ > >>> 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. > >>> > >> > >> > >> > >> -- > >> _______________________________________________________ > >> Jason Schiller|NetOps|jschiller at google.com > >> |571-266-0006 > >> > >> > > > _______________________________________________ > 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. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From rfg at tristatelogic.com Fri May 26 17:36:21 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 26 May 2017 14:36:21 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: Message-ID: <68797.1495834581@segfault.tristatelogic.com> In message , Hostmaster at uneedus.com wrote: >What I would like to hear from the community is their input as to where to >draw the line for 6.5.5.1... What you would like, and what I would like appear to be two dramatically distinct things. I would like to just also offer the observation that I simply cannot remember any time at which anyone has purported to follow-up on any posting I have made to any mailing list while so throughly and comprehensively and utterly failing to even touch on any of the issues that I raised in the post which is allegedly being followed-up on. Perhaps I failed to be completely clear. I will try again. When either these new SWIP rules, for IPv6, or the current SWIP rules, for IPv4 are violated... as they appear to be, with great frequency, from where I am sitting... then who does one call? The Internet Police? From daveid at panix.com Fri May 26 18:01:38 2017 From: daveid at panix.com (David Huberman) Date: Fri, 26 May 2017 18:01:38 -0400 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <68797.1495834581@segfault.tristatelogic.com> References: <68797.1495834581@segfault.tristatelogic.com> Message-ID: <8A3A301D-39B5-4F81-8E2C-90E23B81919E@panix.com> rfg, The mandatory SWIP requirements are an anachronism from a time where they were moderately enforceable. For many many years, a traditional, vanilla-flavored ISP would get a block from ARIN, allocate a lot of it to dynamic pools. SWIP out the static /29 and larger assignments to customers, use the space, then petition ARIN for another block. ARIN would get the utilization detail from the ISP in spreadsheet or flat file format, compare it to what's in Whois (what was SWIPed) and if everything was good, grant the ISP a new block. If the required static assignments were not SWIPed, that was ARIN's stick: no space until you SWIP. And as someone who was a hostmaster there for 10 years during this period, I saw the system basically work. In v6, and today in v4 post-runout, ARIN has no stick. Nobody is coming back for additional v6 allocations. You're really not supposed to. In v4, the transaction has already happened. The ISP (and what is an ISP today? That's a difficult discussion because "ISP" as a network classification is mostly anachronistic within the context of ARIN policy language) has already bought the space from the seller who wasn't using it. If ARIN uses that ticket - the "I bought space please xfer it to my account" - to enforce SWIP requirements on older blocks, and the requirements aren't met, then what? Whois never gets updated and the greater operator community loses the most. In short, there is an argument that the SWIP rules are no-op now. So to answer your question directly; what do you do? Nothing. Those days are long gone and ARIN has other focuses now. Just my opinion, David Sent from my iPhone > On May 26, 2017, at 5:36 PM, Ronald F. Guilmette wrote: > > > In message , > Hostmaster at uneedus.com wrote: > >> What I would like to hear from the community is their input as to where to >> draw the line for 6.5.5.1... > > What you would like, and what I would like appear to be two dramatically > distinct things. > > I would like to just also offer the observation that I simply cannot > remember any time at which anyone has purported to follow-up on any > posting I have made to any mailing list while so throughly and > comprehensively and utterly failing to even touch on any of the > issues that I raised in the post which is allegedly being followed-up > on. > > Perhaps I failed to be completely clear. I will try again. > > When either these new SWIP rules, for IPv6, or the current SWIP rules, > for IPv4 are violated... as they appear to be, with great frequency, > from where I am sitting... then who does one call? The Internet Police? > _______________________________________________ > 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 rfg at tristatelogic.com Fri May 26 18:32:25 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 26 May 2017 15:32:25 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <8A3A301D-39B5-4F81-8E2C-90E23B81919E@panix.com> Message-ID: <68979.1495837945@segfault.tristatelogic.com> In message <8A3A301D-39B5-4F81-8E2C-90E23B81919E at panix.com>, David Huberman wrote: >In short, there is an argument that the SWIP rules are no-op now. So to answer >your question directly; what do you do? Nothing. Those days are long gone >and ARIN has other focuses now. So, let me see if I understand this... ARIN doesn't, can't, and most probably won't either enforce the existing (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be drafted and/or promulgated with respect to IPv6. Is that about the size of it? If so, then color me perplexed. I'm not at all sure that I grasp the reason(s) why people on this list are spending/investing time and energy discussing and debating some new draft rule for IPv6 that also and likewise won't ever actually be enforced. Am I missing something? Regards, rfg P.S. Mind you, I have no objections whatsoever to permitting any and all folks who so desire to participate as much as they want in whatever pointless but pleasant pasttimes amuse them or suit their fancy. It's a free country, after all, or so I am told. I'm just not sure that I understand the pragmatic value in legislating against spitting on the sidewalk at a time when we have just, in effect, laid off all of the beat cops who might ever actually enforce that. From scottleibrand at gmail.com Fri May 26 18:45:58 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 26 May 2017 15:45:58 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <68979.1495837945@segfault.tristatelogic.com> References: <8A3A301D-39B5-4F81-8E2C-90E23B81919E@panix.com> <68979.1495837945@segfault.tristatelogic.com> Message-ID: On Fri, May 26, 2017 at 3:32 PM, Ronald F. Guilmette wrote: > > In message <8A3A301D-39B5-4F81-8E2C-90E23B81919E at panix.com>, > David Huberman wrote: > > >In short, there is an argument that the SWIP rules are no-op now. So to > answer > >your question directly; what do you do? Nothing. Those days are long gone > >and ARIN has other focuses now. > > So, let me see if I understand this... > > ARIN doesn't, can't, and most probably won't either enforce the existing > (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be > drafted and/or promulgated with respect to IPv6. Is that about the size > of it? > Pretty much, unless someone comes up with a new method of enforcing SWIP rules. Some of the discussions with law enforcement could eventually result in such carrots or sticks, but no one has proposed any specifics yet. > > If so, then color me perplexed. I'm not at all sure that I grasp the > reason(s) why people on this list are spending/investing time and energy > discussing and debating some new draft rule for IPv6 that also and likewise > won't ever actually be enforced. > Am I missing something? > No, this proposal isn't drafting a new rule, but rather relaxing an existing one that mostly isn't being observed or enforced, so that people who follow the rules and those who don't are on a level playing field. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From cja at daydream.com Fri May 26 19:08:52 2017 From: cja at daydream.com (Cj Aronson) Date: Fri, 26 May 2017 17:08:52 -0600 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <8A3A301D-39B5-4F81-8E2C-90E23B81919E@panix.com> <68979.1495837945@segfault.tristatelogic.com> Message-ID: Scott, On Fri, May 26, 2017 at 4:45 PM, Scott Leibrand wrote: > On Fri, May 26, 2017 at 3:32 PM, Ronald F. Guilmette < > rfg at tristatelogic.com> wrote: > >> >> In message <8A3A301D-39B5-4F81-8E2C-90E23B81919E at panix.com>, >> David Huberman wrote: >> >> >In short, there is an argument that the SWIP rules are no-op now. So to >> answer >> >your question directly; what do you do? Nothing. Those days are long gone >> >and ARIN has other focuses now. >> >> So, let me see if I understand this... >> >> ARIN doesn't, can't, and most probably won't either enforce the existing >> (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be >> drafted and/or promulgated with respect to IPv6. Is that about the size >> of it? >> > > Pretty much, unless someone comes up with a new method of enforcing SWIP > rules. Some of the discussions with law enforcement could eventually > result in such carrots or sticks, but no one has proposed any specifics yet. > There is this draft policy that has a few "sticks" at least for delegations to downstream ISPs. https://www.arin.net/policy/proposals/2017_3.html > > >> >> ----Cathy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Fri May 26 19:10:10 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 26 May 2017 19:10:10 -0400 (EDT) Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <68797.1495834581@segfault.tristatelogic.com> References: <68797.1495834581@segfault.tristatelogic.com> Message-ID: > > When either these new SWIP rules, for IPv6, or the current SWIP rules, > for IPv4 are violated... as they appear to be, with great frequency, > from where I am sitting... then who does one call? The Internet Police? The only real "Police" is when ARIN uses the SWIP data to justify another allocation of space. If the entries are not in place, ARIN does not consider it in use, and the holder cannot get another allocation. In the case of v4, often the records were only put in place right before attempting to get another allocation. Right before the v4 jar ran out, using the cable operator rule, Comcast received a /9, which was quite a lot, but the SWIP of their infrastructure assignments were in place so they could justify that request. Without that data, they would have never received that allocation. That was the largest allocation right before the v4 space in ARIN ran out. Im sure other operators got their records in place, so that they could get some of that v4 pie before it ran out. Now that the v4 pie is gone, as others have said the reason behind why to SWIP is gone as well. In the case of v6, there seems to be some operators like the tunnel brokers who have SWIP'ed everyone without fail. Other operators seem to totally ignore this requirement. In my case, I have 2 upstream providers, who have both provided me with a /48. In the case of the older tunnel broker operator, the addresses are registered, but in the case of the other one, the only registration for the entire block is the ISP itself, there are no assignments at all on records. >From the ISP prospective, unless you are a giant, almost noone is going to ever have to go back for more than their initial /32. If they give everyone a /48, that is 65k assignments, and if they chose a /56 that expands that number 256 fold. The only real "Internet Police" stick is the records needed for additional assignments must be there before you can get more. If in fact more is never needed because of the size of the initial allocation, there is zero incentive to SWIP the customers, and I think this will get worse as we move toward v6 as the main protocol on the internet. Albert Erdmann Network Administrator Paradise On Line Inc. From rfg at tristatelogic.com Fri May 26 19:26:44 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 26 May 2017 16:26:44 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: Message-ID: <69242.1495841204@segfault.tristatelogic.com> In message Scott Leibrand wrote: >> So, let me see if I understand this... >> >> ARIN doesn't, can't, and most probably won't either enforce the existing >> (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be >> drafted and/or promulgated with respect to IPv6. Is that about the size >> of it? > >Pretty much, unless someone comes up with a new method of enforcing SWIP >rules. Some of the discussions with law enforcement could eventually >result in such carrots or sticks... :-) Oh yea, I'm completely sure that everyone will be on board for THAT! Let's get the Real Police to be the Internet Police. Yessir. I'm sure that nobody will voice any objections to THAT idea. :-) >> Am I missing something? > >No, this proposal isn't drafting a new rule, but rather relaxing an >existing one that mostly isn't being observed or enforced, so that people >who follow the rules and those who don't are on a level playing field. I've been sitting here, reading and re-reading the above sentence, several times, for the past few minutes, hoping that I'd be able to read it deeply enough so that it would eventually convey to me some not-totally-illogical thought or idea or concept, but before that actually occurred, my head exploded. The fundamental problem is that I can't even begin to wrap my head around -any- understanding of -any- alternative universe in which having those who play by the rules and those who don't be "on a level playing field" is either a Good Thing or a Desirable Thing. My utter befuddlement was furthermore raised to a higher power by taking into account also the notion of different groups being placed "on a level playing field" with respect to rules that... as you noted earlier in the same sentence... aren't even being enforced. Aren't we all, already, and by definition, "on a level playing field" with respect to any and all rules, laws, statutes, commandments, or edicts which are not being actively enforced? Mind you, I am not complaining, or blaming you for having caused my head to explode. (I need that from time to time anyway.) But you do owe me a new keyboard due to the fact that my exploded brains are now splattered all over this one, making it throughly unusable. Anyway, actually, you have my compliments. The sentence of your's last quoted above is, I think, worthy of Salvadore Dali and/or Joseph Heller. And ernestly, I cannot help but admire such extraordinary, artful, and artistic use of the English language. Regards, rfg From peter.thimmesch at addrex.net Fri May 26 19:34:32 2017 From: peter.thimmesch at addrex.net (Peter Thimmesch) Date: Fri, 26 May 2017 23:34:32 +0000 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <8A3A301D-39B5-4F81-8E2C-90E23B81919E@panix.com> <68979.1495837945@segfault.tristatelogic.com> , Message-ID: Hello Cathy, Yes, the was some rather heated discussion at the ARIN meeting in New Orleans about the proposed wording in 3.6.7 Non-Responsive Point of Contact Records. I believe, please correct me if you think otherwise, that the consensus of opinions that spoke at the meeting were strongly against the removing of records from public Whois. Therefore pointing someone to consider this type of punitive action would be seemingly designed to do what? What problem is trying to be solved with this proposed policy? Is it to align the two existing policies or to create a punitive measure? Regards, Peter Thimmesch On May 26, 2017, at 19:09, Cj Aronson > wrote: Scott, On Fri, May 26, 2017 at 4:45 PM, Scott Leibrand > wrote: On Fri, May 26, 2017 at 3:32 PM, Ronald F. Guilmette > wrote: In message <8A3A301D-39B5-4F81-8E2C-90E23B81919E at panix.com>, David Huberman > wrote: >In short, there is an argument that the SWIP rules are no-op now. So to answer >your question directly; what do you do? Nothing. Those days are long gone >and ARIN has other focuses now. So, let me see if I understand this... ARIN doesn't, can't, and most probably won't either enforce the existing (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be drafted and/or promulgated with respect to IPv6. Is that about the size of it? Pretty much, unless someone comes up with a new method of enforcing SWIP rules. Some of the discussions with law enforcement could eventually result in such carrots or sticks, but no one has proposed any specifics yet. There is this draft policy that has a few "sticks" at least for delegations to downstream ISPs. https://www.arin.net/policy/proposals/2017_3.html ----Cathy _______________________________________________ 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 rfg at tristatelogic.com Fri May 26 19:46:08 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 26 May 2017 16:46:08 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: Message-ID: <69313.1495842368@segfault.tristatelogic.com> In message , hostmaster at uneedus.com wrote: >In the case of v4, often the records were only put in place right before >attempting to get another allocation... Yes. I myself can still remember, back in the day... before the law changed in my state... throwing the roach out the car window, just after being lit up with the whirling red and blue lights, but before the cop could actually pull me over. Ah, to be young and reckless again! 'Tis a thing to be wished for. Anyway, it is somwhow strangely reassuring to know that IPv4 allocation holders have often been every bit the scofflaws that I myself was, back in the day. decades ago. >>From the ISP prospective, unless you are a giant, almost noone is going to >ever have to go back for more than their initial /32. If they give >everyone a /48, that is 65k assignments, and if they chose a /56 that >expands that number 256 fold. > >The only real "Internet Police" stick is the records needed for additional >assignments must be there before you can get more. If in fact more is >never needed because of the size of the initial allocation, there is zero >incentive to SWIP the customers... So, if I may summarize, the current discussion of a change to the existing SWIP rule for IPv6... the civilized discussion that I wantonly and shamlessly barged, uninvited, into the middle of... in the end all amounts to a debate about how many angelic /48s can dance on the head of a pin? Regards, rfg From hostmaster at uneedus.com Fri May 26 20:11:10 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 26 May 2017 20:11:10 -0400 (EDT) Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <68979.1495837945@segfault.tristatelogic.com> References: <68979.1495837945@segfault.tristatelogic.com> Message-ID: > So, let me see if I understand this... > > ARIN doesn't, can't, and most probably won't either enforce the existing > (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be > drafted and/or promulgated with respect to IPv6. Is that about the size > of it? > > If so, then color me perplexed. I'm not at all sure that I grasp the > reason(s) why people on this list are spending/investing time and energy > discussing and debating some new draft rule for IPv6 that also and likewise > won't ever actually be enforced. > > Am I missing something? I am the proposer of the current item regarding IPv6 Assignment Registration. I wrote this proposal with all seriousness, and do not see it as head of a pin dancing. When the rules for v4 likely affect less than 5-10% of the total customer base at an ISP, but adding IPv6 elevates it to 100%, this is wrong, and this does deserve a serious shot at repair. I would like to see the percentages of v6 customers subject to this rule to be roughly the same as the current number of v4 customers subject to the rule. In the IPv4 world, a majority of the total number of access circuits for Internet access only provide 1 global IP address. In the case of mobile networks, you do not even get that, but rather an RFC1918 address behind some sort of NAT. The current rule of /29 or more means that all these IPv4 customers are not, and never have been subject to SWIP rules. Generally only those doing hosting of some sort, or larger businesses actually request an amount of addresses that require SWIP. Therefore, while we discuss how many access providers are ignoring the SWIP rules, do remember that the majority of ISP customers for IPv4 internet access are NOT subject to the SWIP rules, since they have 1 or less dedicated IP addresses. Only the largest IPv4 customers are subject to SWIP, not the majority of the total customer base. When the standard was lowered to the /29 point, somehow the proposal at that time also decided to lower the v6 point from /48 to /64. Of course, /64 means EVERY customer, even the very smallest must be subject to SWIP under the rules. As noted we have gone a few years with only a few people requesting v6 assignments, and the SWIP requirement has been ignored to a large degree much to the same degree that v6 itself has been ignored. The current rule for IPv6 is 100% is subject to SWIP. Whereas maybe 10% or less of your customer base under v4 was subject to SWIP, the current requirement is 100% for v6. How can you expect such a rule to be followed, and is it reasonable to subject the majority of the access customers to this rule for v6, when it has NEVER been the rule in v4? I have never seen anyone propose SWIP at the /32 level. The current v6 standard of 100% SWIP is UNREASONABLE. This is why I am proposing a change in the standard. Reasonable rules are more likely to be complied with, and whatever the rule is, I agree that the rules should not be ignored, and also agree that in fact, it is widely ignored. If it were made more reasonable, I have hope that it might also be followed more. If the Registration rule was made closer to the current v4 rule, such that does not catch most access provider customers, there will be fewer addresses to SWIP, and I believe it will be more likely than the current rule to be followed, as the number of assignments requiring registration will be vastly decreased from the current standard of 100% of v6. While I doubt that this registration requirement is the "cause" of not providing IPv6 connections, it certainly adds to the excuses not to adopt. We know that lots of excuses have been used, and we should do anything to cut back on the excuses. In answer to the question as to the purpose of this proposal, it is to make the rules for SWIP more equal between IPv4 and IPv6. Currently, IPv4 only requires SWIP for a /29 or more, leaving the majority of access circuits without any SWIP requirement whatsoever. This is NOT currently true for IPv6, which the policy manual requires registration for a /64 or more of space, which is basically 100%. Albert Erdmann Network Administrator Paradise On Line Inc. From peter.thimmesch at addrex.net Fri May 26 20:25:24 2017 From: peter.thimmesch at addrex.net (Peter Thimmesch) Date: Sat, 27 May 2017 00:25:24 +0000 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <68979.1495837945@segfault.tristatelogic.com>, Message-ID: <61220AB4-1F3D-4082-A380-2943117A91F0@addrex.net> Albert, I concur 100% with your goal here and believe that there is a path to creating an equitable policy. Therefore I support, and ask others responding to this thread, with the intent of your policy proposal. The sole question, outside of "size" of the v6 cut-off, is whether there should be a mechanism to "punish" those that do not follow the policy. Can we work first to agree on the size cut-off and then address what, if any, enforcement tools can be agreed upon? The draft proposed "more than a /60", is this acceptable to the community? I support revising the current policy to this size. Regards, Peter Thimmesch On May 26, 2017, at 20:11, "hostmaster at uneedus.com" wrote: >> So, let me see if I understand this... >> >> ARIN doesn't, can't, and most probably won't either enforce the existing >> (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be >> drafted and/or promulgated with respect to IPv6. Is that about the size >> of it? >> >> If so, then color me perplexed. I'm not at all sure that I grasp the >> reason(s) why people on this list are spending/investing time and energy >> discussing and debating some new draft rule for IPv6 that also and likewise >> won't ever actually be enforced. >> >> Am I missing something? > > I am the proposer of the current item regarding IPv6 Assignment Registration. > > I wrote this proposal with all seriousness, and do not see it as head of a pin dancing. When the rules for v4 likely affect less than 5-10% of the total customer base at an ISP, but adding IPv6 elevates it to 100%, this is wrong, and this does deserve a serious shot at repair. I would like to see the percentages of v6 customers subject to this rule to be roughly the same as the current number of v4 customers subject to the rule. > > In the IPv4 world, a majority of the total number of access circuits for Internet access only provide 1 global IP address. In the case of mobile networks, you do not even get that, but rather an RFC1918 address behind some sort of NAT. The current rule of /29 or more means that all these IPv4 customers are not, and never have been subject to SWIP rules. Generally only those doing hosting of some sort, or larger businesses actually request an amount of addresses that require SWIP. > > Therefore, while we discuss how many access providers are ignoring the SWIP rules, do remember that the majority of ISP customers for IPv4 internet access are NOT subject to the SWIP rules, since they have 1 or less dedicated IP addresses. > > Only the largest IPv4 customers are subject to SWIP, not the majority of the total customer base. > > When the standard was lowered to the /29 point, somehow the proposal at that time also decided to lower the v6 point from /48 to /64. Of course, /64 means EVERY customer, even the very smallest must be subject to SWIP under the rules. As noted we have gone a few years with only a few people requesting v6 assignments, and the SWIP requirement has been ignored to a large degree much to the same degree that v6 itself has been ignored. > > The current rule for IPv6 is 100% is subject to SWIP. Whereas maybe 10% or less of your customer base under v4 was subject to SWIP, the current requirement is 100% for v6. > > How can you expect such a rule to be followed, and is it reasonable to subject the majority of the access customers to this rule for v6, when it has NEVER been the rule in v4? I have never seen anyone propose SWIP at the /32 level. The current v6 standard of 100% SWIP is UNREASONABLE. This is why I am proposing a change in the standard. > > Reasonable rules are more likely to be complied with, and whatever the rule is, I agree that the rules should not be ignored, and also agree that in fact, it is widely ignored. If it were made more reasonable, I have hope that it might also be followed more. > > If the Registration rule was made closer to the current v4 rule, such that does not catch most access provider customers, there will be fewer addresses to SWIP, and I believe it will be more likely than the current rule to be followed, as the number of assignments requiring registration will be vastly decreased from the current standard of 100% of v6. > > While I doubt that this registration requirement is the "cause" of not providing IPv6 connections, it certainly adds to the excuses not to adopt. > We know that lots of excuses have been used, and we should do anything to cut back on the excuses. > > In answer to the question as to the purpose of this proposal, it is to make the rules for SWIP more equal between IPv4 and IPv6. Currently, IPv4 only requires SWIP for a /29 or more, leaving the majority of access circuits without any SWIP requirement whatsoever. This is NOT currently true for IPv6, which the policy manual requires registration for a /64 or more of space, which is basically 100%. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > _______________________________________________ > 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 daveid at panix.com Fri May 26 20:31:38 2017 From: daveid at panix.com (David R Huberman) Date: Fri, 26 May 2017 20:31:38 -0400 (EDT) Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <68979.1495837945@segfault.tristatelogic.com> Message-ID: Albert, First, I wanted to say that both as a member of the community (as a network operator) and as an AC member, I was exceedingly happy when you proposed this draft policy. I don't agree with everything you have written, but I agree with a lot of it, and I think the draft policy language is a good starting point. Just as (or possibly more) importantly, I wanted us to have the discussion we're having about the purpose of SWIPs. Because as I wrote to rfg, I see the SWIP policy as an anachronism, and I think it's time we really dig into the policies and figure out where they should go. Second, I'd like to ask you to please stop referring to specific companies by name. We purposely talk in broad concepts because policy applies to large swaths of companies -- entire classes of networks -- not just "ISP X". It's fine to say "I have watched a certain cableco not play by the rules" to get your point across, for example :) Now, some specific feedback: > I wrote this proposal with all seriousness, and do not see it as head of > a pin dancing. When the rules for v4 likely affect less than 5-10% of > the total customer base at an ISP, but adding IPv6 elevates it to 100%, > this is wrong, and this does deserve a serious shot at repair. I would > like to see the percentages of v6 customers subject to this rule to be > roughly the same as the current number of v4 customers subject to the > rule. I agree. [snip of the logical argument backing up the claims of inequity between v4 and v6 policy.] > How can you expect such a rule to be followed, and is it reasonable to > subject the majority of the access customers to this rule for v6, when > it has NEVER been the rule in v4? I have never seen anyone propose SWIP > at the /32 level. The current v6 standard of 100% SWIP is UNREASONABLE. > This is why I am proposing a change in the standard. Again, I agree. > Reasonable rules are more likely to be complied with, and whatever the > rule is, I agree that the rules should not be ignored, and also agree > that in fact, it is widely ignored. If it were made more reasonable, I > have hope that it might also be followed more. > > If the Registration rule was made closer to the current v4 rule, such that > does not catch most access provider customers, there will be fewer addresses > to SWIP, and I believe it will be more likely than the current rule to be > followed, as the number of assignments requiring registration will be vastly > decreased from the current standard of 100% of v6. That makes sense. I'm not sure I agree (and I'm not sure I disagree), but I can accept your posulation. > In answer to the question as to the purpose of this proposal, it is to make > the rules for SWIP more equal between IPv4 and IPv6. Currently, IPv4 only > requires SWIP for a /29 or more, leaving the majority of access circuits > without any SWIP requirement whatsoever. This is NOT currently true for > IPv6, which the policy manual requires registration for a /64 or more of > space, which is basically 100%. So to make them more equal, I actually preferred your approach - lower the v4 threshold and lower the v6 threshold. I think anything smaller than a /24 is not helpful. But I suspect I'm in a small minority there, so I'll just assume it's never going to happen :) For this policy, I'd prefer a SWIP if it's a /48 or larger. Subnets smaller than a /48 are not typically going to ever be independently routed, and that's my interest in SWIP policy. Thanks again for submitting and defending your policy proposal! David From kevinb at thewire.ca Fri May 26 21:33:14 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Sat, 27 May 2017 01:33:14 +0000 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <61220AB4-1F3D-4082-A380-2943117A91F0@addrex.net> References: <68979.1495837945@segfault.tristatelogic.com>, <61220AB4-1F3D-4082-A380-2943117A91F0@addrex.net> Message-ID: <7E7773B523E82C478734E793E58F69E78E6EC92F@SBS2011.thewireinc.local> Peter, I agree that this policy should be about the sizing of SWIP assignments in IPv6 only. I would prefer that any issue related to enforcement be left out of the policy (I don't see it in the current draft). The benefit of having an appropriate size, is that it shows the community what the expectation should be. Regarding the size, this is only for customers that specify the need for a static assignment. A customer being assigned a dynamic /48 would not apply etc. The smaller the block, the more customers will be shoe horned into the wrong assignment size, for the sake of paperwork. I believe that larger than /56 should be the bar. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Peter Thimmesch Sent: Friday, May 26, 2017 8:25 PM To: hostmaster at uneedus.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv4 SWIP requirements (?) Albert, I concur 100% with your goal here and believe that there is a path to creating an equitable policy. Therefore I support, and ask others responding to this thread, with the intent of your policy proposal. The sole question, outside of "size" of the v6 cut-off, is whether there should be a mechanism to "punish" those that do not follow the policy. Can we work first to agree on the size cut-off and then address what, if any, enforcement tools can be agreed upon? The draft proposed "more than a /60", is this acceptable to the community? I support revising the current policy to this size. Regards, Peter Thimmesch On May 26, 2017, at 20:11, "hostmaster at uneedus.com" wrote: >> So, let me see if I understand this... >> >> ARIN doesn't, can't, and most probably won't either enforce the >> existing >> (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may >> be drafted and/or promulgated with respect to IPv6. Is that about >> the size of it? >> >> If so, then color me perplexed. I'm not at all sure that I grasp the >> reason(s) why people on this list are spending/investing time and >> energy discussing and debating some new draft rule for IPv6 that also >> and likewise won't ever actually be enforced. >> >> Am I missing something? > > I am the proposer of the current item regarding IPv6 Assignment Registration. > > I wrote this proposal with all seriousness, and do not see it as head of a pin dancing. When the rules for v4 likely affect less than 5-10% of the total customer base at an ISP, but adding IPv6 elevates it to 100%, this is wrong, and this does deserve a serious shot at repair. I would like to see the percentages of v6 customers subject to this rule to be roughly the same as the current number of v4 customers subject to the rule. > > In the IPv4 world, a majority of the total number of access circuits for Internet access only provide 1 global IP address. In the case of mobile networks, you do not even get that, but rather an RFC1918 address behind some sort of NAT. The current rule of /29 or more means that all these IPv4 customers are not, and never have been subject to SWIP rules. Generally only those doing hosting of some sort, or larger businesses actually request an amount of addresses that require SWIP. > > Therefore, while we discuss how many access providers are ignoring the SWIP rules, do remember that the majority of ISP customers for IPv4 internet access are NOT subject to the SWIP rules, since they have 1 or less dedicated IP addresses. > > Only the largest IPv4 customers are subject to SWIP, not the majority of the total customer base. > > When the standard was lowered to the /29 point, somehow the proposal at that time also decided to lower the v6 point from /48 to /64. Of course, /64 means EVERY customer, even the very smallest must be subject to SWIP under the rules. As noted we have gone a few years with only a few people requesting v6 assignments, and the SWIP requirement has been ignored to a large degree much to the same degree that v6 itself has been ignored. > > The current rule for IPv6 is 100% is subject to SWIP. Whereas maybe 10% or less of your customer base under v4 was subject to SWIP, the current requirement is 100% for v6. > > How can you expect such a rule to be followed, and is it reasonable to subject the majority of the access customers to this rule for v6, when it has NEVER been the rule in v4? I have never seen anyone propose SWIP at the /32 level. The current v6 standard of 100% SWIP is UNREASONABLE. This is why I am proposing a change in the standard. > > Reasonable rules are more likely to be complied with, and whatever the rule is, I agree that the rules should not be ignored, and also agree that in fact, it is widely ignored. If it were made more reasonable, I have hope that it might also be followed more. > > If the Registration rule was made closer to the current v4 rule, such that does not catch most access provider customers, there will be fewer addresses to SWIP, and I believe it will be more likely than the current rule to be followed, as the number of assignments requiring registration will be vastly decreased from the current standard of 100% of v6. > > While I doubt that this registration requirement is the "cause" of not providing IPv6 connections, it certainly adds to the excuses not to adopt. > We know that lots of excuses have been used, and we should do anything to cut back on the excuses. > > In answer to the question as to the purpose of this proposal, it is to make the rules for SWIP more equal between IPv4 and IPv6. Currently, IPv4 only requires SWIP for a /29 or more, leaving the majority of access circuits without any SWIP requirement whatsoever. This is NOT currently true for IPv6, which the policy manual requires registration for a /64 or more of space, which is basically 100%. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > _______________________________________________ > 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 hostmaster at uneedus.com Fri May 26 21:33:49 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 26 May 2017 21:33:49 -0400 (EDT) Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <61220AB4-1F3D-4082-A380-2943117A91F0@addrex.net> References: <68979.1495837945@segfault.tristatelogic.com>, <61220AB4-1F3D-4082-A380-2943117A91F0@addrex.net> Message-ID: On Sat, 27 May 2017, Peter Thimmesch wrote: > Albert, > > I concur 100% with your goal here and believe that there is a path to > creating an equitable policy. Therefore I support, and ask others > responding to this thread, with the intent of your policy proposal. > > The sole question, outside of "size" of the v6 cut-off, is whether there > should be a mechanism to "punish" those that do not follow the policy. > > Can we work first to agree on the size cut-off and then address what, if > any, enforcement tools can be agreed upon? > > The draft proposed "more than a /60", is this acceptable to the > community? I support revising the current policy to this size. > > Regards, > > Peter Thimmesch My proposal has nothing whatsover to do with enforcement of the SWIP requirements. My proposal is only about what point, such as "more than a /60" should the policy requiring assignment registration be set for v6. I have learned enough to suggest that the portion of my proposal to raise the v4 standard above /29 in the name of equality appears to not have support. Thus, I am no longer advocating this change at all. As to where the v6 line should be drawn, many commenters as well as myself agree that /64 is too low, as even small networks should be able to subnet itself for security and isolation reasons. If there is anyone here who thinks that a /64 is enough and should be the line, lets hear the reasons. My proposal is currently "More than a /60" which gives 16 subnets. For most uses today, this is plenty, but others have suggested it be /56 or even one comment of /48. Since we should remain on a nibble boundary, the choices are /48, /52, /56, /60 or /64. The biggest network currently not requiring assignment registration under current policy is a /65, a non- standard network size. I would like to stay focused on what size network on a nibble boundary should the maximum be before triggering the assignment registration policy. Other than /64, I would be happy with any of the other boundaries listed above. Enforcement I think should be left to another proposal, and do not think that I am the one that will be drafting such a proposal, and do not think the enforcement issues are helpful in trying to decide where the boundary should be drawn in this policy proposal. Please reserve these discussions for a future "enforcement" policy proposal, when we can discuss the need for SWIP, and the privacy implications for small networks. Currently 100% SWIP is required for ALL v6 assignments of /64 or larger. The residential customer is exempt from disclosure of street address and name, BUT a zip code/postal code is disclosed. Will we start seeing geolocation providers using this data? Albert Erdmann Network Administrator Paradise On Line Inc. From jcurran at arin.net Fri May 26 21:47:54 2017 From: jcurran at arin.net (John Curran) Date: Sat, 27 May 2017 01:47:54 +0000 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <68979.1495837945@segfault.tristatelogic.com>, <61220AB4-1F3D-4082-A380-2943117A91F0@addrex.net>, Message-ID: <37601B52-B8FB-4661-89AB-21052CF28F8B@arin.net> On May 26, 2017, at 9:35 PM, "hostmaster at uneedus.com" wrote: > ... > Enforcement I think should be left to another proposal, and do not think that I am the one that will be drafting such a proposal, and do not think the enforcement issues are helpful in trying to decide where the boundary should be drawn in this policy proposal. Indeed. As folks are probably aware, ARIN is quite willing to enforce SWIP requirements in whatever manner the community deems appropriate, we simply ask for clear direction in the form of community-developed policy. Thanks! /John John Curran President and CEO ARIN From rfg at tristatelogic.com Fri May 26 21:54:34 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 26 May 2017 18:54:34 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: Message-ID: <69892.1495850074@segfault.tristatelogic.com> In message , hostmaster at uneedus.com wrote: >Only the largest IPv4 customers are subject to SWIP, not the majority of >the total customer base. Just when I though that I was beginning to understand, now I am *really* confused. You say "Only the largest IPv4 customers are subject to SWIP", but I have no idea if, when you talk about "IPv4 customers" you really only mean to refer to those IPv4 users that obtain direct allocations from ARIN (?) If you meant instead all IPv4 users, then quite obviously, your statement is -not- true, since the IPv4 SWIP rule applies to anything and anybody who has a /29 or larger, and many of these entities are clearly by no means "the largest IPv4 customers". And even if we talk only about those obtaining direct allocations from ARIN, I've seen many hosting companies that have only a /22 or sometimes even smaller, and yet it would seem to me that when they give out sub-blocks of /29 or larger, they are clearly subject to the rule, and yet many of these are also by no means "the largest IPv4 customers". So, either way you elect define the term "IPv4 customer" it would seem to me that the assertion you just made is falacious on its face, and that in fact many entities that do not qualify as being "big" in any sense are arguably subject to the existing SWIP rule for IPv4. >When the standard was lowered to the /29 point, somehow the proposal at >that time also decided to lower the v6 point from /48 to /64. Of course, >/64 means EVERY customer, even the very smallest must be subject to SWIP >under the rules. You say that like its a bad thing. I don't know about you, but where I live, even the smallest cars are required to have documentation and a valid license plate in order to travel on public roadways: http://www.toxel.com/wp-content/uploads/2010/06/smallcars02.jpg It's just a matter of public safety. A very slight and small inconvenience for everyone, for the sake of the greater common public good. >... the current {SWIP} requirement is 100% for v6. > >How can you expect such a rule to be followed, and is it reasonable to >subject the majority of the access customers to this rule for v6, when it >has NEVER been the rule in v4? I would have to agree that there would seem to be an imbalance of (un)fairness there. I'm not persuaded that the correct solution is to loosen the rules so as to allow more people with "small" cars to drive around without license plates. But to reiterate, all of this is pretty much meaningless anyway, given the context of absolute non-enforcement of the rules for both IPv4 and IPv6. >I have never seen anyone propose SWIP at the /32 level. Oh! Well! Please then, please allow me to be the first to do so! (And now I shall duck discreetly behind a curtain, so as to avoid being struck by the inevitable bits of rotten fruits and vegatables being tossed, furiously, in the general direction of my head.) >The current v6 standard of 100% SWIP is UNREASONABLE. I feel quite sure that at the time when the notion of automobile license plates was first proposed, many stood up and raised the exact same objection, i.e. that the new rule was totally unreasonable, especially as it was to be applied to literally -every- powered vehicle operating on public highways. And yet here we are, a century or so later, and yet these days the relevant Wikipedia page doesn't even contain a "Controversy" subsection, and most probably, every person who has ever been struck in a hit-and-run incident may wonder how we ever did without them. https://en.wikipedia.org/wiki/Vehicle_registration_plate#United_States >Reasonable rules are more likely to be complied with, and whatever the >rule is, I agree that the rules should not be ignored, and also agree that >in fact, it is widely ignored. If it were made more reasonable, I have >hope that it might also be followed more. As I made reference to earlier, in my own state of California, we have not long ago legalized recreational marijuana. Now *everyone* within the state, both pot heads and non- pot heads, can be said to follow the law. If the goal is to establish a more law-abiding society, then it cannot be argued that this is quite certainly one way to achieve that, i.e. simply eliminating the existing legal restriction. Some might well argue however that this is sort-of a perverse and back-handed way of achieving universal compliance with the law. (That is not to say that this approach is lacking in merit. It certainly appears to have yielded tangible benefits, e.g. at and after the time of the repeal of prohibition.) >If the Registration rule was made closer to the current v4 rule, such that >does not catch most access provider customers, there will be fewer >addresses to SWIP, and I believe it will be more likely than the current >rule to be followed... Your motives and goals are admirable, but in the utter absence of any kind of meaningful enforcement, of either the existing rules or the proposed modified ones, I personally cannot envision there being any notable or substantial difference in the actual behavior of the community as a whole, no matter what the fine details of the relevant (unenforced) rules might be. This is not actually an argument against your proposal, and it would be wrong to interpret it that way. This is a argument *for* the actual enforcement of The Rules, whatever they may be, at any given moment. In the utter absence of such enforcement, the rules themselves become nothing other than an object of well-deserved ridicule, as it appears they are, at the present time. Regards, rfg From ken.mix at clearfly.net Fri May 26 23:37:48 2017 From: ken.mix at clearfly.net (Ken Mix) Date: Sat, 27 May 2017 03:37:48 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <59248105.8040703@arin.net> References: <59248105.8040703@arin.net> Message-ID: Hello, I'd like to register another vote in support of relaxing IPv6 SWIP requirements in 6.5.5.1 to /60, but eliminating the 4.2.3.7.1 IPv4 changes from this proposal. Regards, Ken Mix -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, May 23, 2017 12:36 To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On 18 May 2017, the ARIN Advisory Council (AC) accepted "ARIN-prop-240: Equalization of Assignment Registration requirements between IPv4 and IPv6" as a Draft Policy. Draft Policy ARIN-2017-5 is below and can be found at: https://www.arin.net/policy/proposals/2017_5.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP 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, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Problem Statement: Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address or less (CGnat), which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6. Currently, assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4. IPv6 assignments are therefore treated stricter than IPv4 assignments. The policy should treat both protocols the same. A typical ISP serving residential and small business customers with both IPv4 and IPv6 would typically provide the following assignments to each customer site: /32 (one IP) of IPv4 and a /64 (one network) of IPv6. Under the current policy, that small network customer is exempt from registration for their IPv4 assignment, but the ISP would be required to register ALL IPv6 customers, even those of this smallest network size. In actual fact, most ISP's that are providing their customers with a /64 or more of IPv6 space are not in fact registering this fact with ARIN, even though 6.5.5.1 clearly requires this. It is my belief that these residential and small business customers should not require registration if they did not require registration for the same size IPv4 network, including routers with Vlan and other security support. and thus I propose to make the standard for registration only those customers that have more than 16 IPv4 addresses or 16 IPv6 /64 networks. This would treat IPv6 the same as IPv4. Policy statement: Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to "more than a /28". Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to "more than a /60". Comments: Timetable for implementation: Policy should be adopted as soon as possible, as the new administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. IPv6 should not be more burdensome than the equivalent IPv4 network size. Anything else: The specific sizes chosen set the point of registration for each site to more than 16 networks or addresses, so that those with 16 or less networks (IPv6 /60) or addresses (IPv4 /28) have no registration requirement. This change will result in both protocols being treated exactly the same, and removes residential and small business accounts from any registration requirement with ARIN, and the burden that will create for all ISP's. There are those that might argue that a residental customer will never have a need for more than a /64 of IPv6. Clearly this is false in an IOT and/or wireless world, as many routers already provide a separate address range for wired vs wireless to prevent wired hacking via the wireless space, and also may provide a guest wireless SSID apart from the one provided to the regular users of that same network. Such separation in the IPv4 world is currently done in RFC1918 space using NAT. In IPv6, the equivalent must be done with different /64 blocks. Since good security practices require use at least 2 /64 blocks for wireless and/or IOT isolation, this would require a minimum of a /60 of IPv6 space or up to 16 networks or vlans, an amount that is consistent with a residential or small business network. This type network does not trigger registration under the current IPv4 policy, and its equal should not trigger registration with ARIN based on the current IPv6 policy as is currently the case, and thus, this policy needs to be changed. _______________________________________________ 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 hostmaster at uneedus.com Sat May 27 00:10:25 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Sat, 27 May 2017 00:10:25 -0400 (EDT) Subject: [arin-ppml] IPv4 SWIP requirements Message-ID: On Fri, 26 May 2017, Ronald F. Guilmette wrote: > > In message , > hostmaster at uneedus.com wrote: > >> Only the largest IPv4 customers are subject to SWIP, not the majority of >> the total customer base. > > Just when I though that I was beginning to understand, now I am *really* > confused. You say "Only the largest IPv4 customers are subject to SWIP", > but I have no idea if, when you talk about "IPv4 customers" you really > only mean to refer to those IPv4 users that obtain direct allocations from > ARIN (?) If you meant instead all IPv4 users, then quite obviously, > your statement is -not- true, since the IPv4 SWIP rule applies to > anything and anybody who has a /29 or larger, and many of these entities > are clearly by no means "the largest IPv4 customers". I guess I did not make it very clear what I meant. When I said "largest", I meant the numeric majority of total customers that have only a single v4, rather than the "smallest", those customers that choose to obtain 8 or more v4 addresses. An average ISP has many customers. The majority of the total number of customers of an ISP use only one IPv4 address and trigger no SWIP v4 requirement. Only a few of the total number of customers request an /29 or more, and these are likely businesses that host their own servers on the assigned addresses, and only these addresses must be SWIP'ed. As an example, ISP X has 1,000,000 customers, of which 10,000 or 1% request 8 or more IPv4 addresses. This ISP must create SWIP records for all 10,000 of those with 8 or more v4 addreses. There is no requirement to create any SWIP records for the remaining 990,000 customers, of which almost all of them very likely only have a /32 of v4 assigned to them. Now, ISP X has decided that because they can no longer get any v4 space from ARIN, that they are going to provide a /64 of v6 network addresses to all its customers, and place all new customers behind a v4 CGnat gateway. Since each of the customers will be assigned a v6 /64, current ARIN policy requires ISP X to register each of these /64 v6 assignments in SWIP. Same minimum possible size network for both v4 and v6, but there is now an additional expense for ISP X to register ALL their customers in SWIP. If ISP X had not provided v6, they would only have to SWIP 10,000 address ranges for the small share of customers who have a /29 or more of v4 space. These customers likely pay more for the additional IPv4 addresses per month, and this charge helps pay the administrative cost of the SWIP registration. However, since they have chosen the "right" thing and decided to provide both v4 and v6, they now have an additional 1,000,000 records to add to SWIP, or 1,100,000 in total, and this cost is across ALL of its customers, not just the ones who elected to get additional address space. The majority of most ISP customers have less than 8 v4 addresses, and in fact usually just one (or none in the case of CGnat). When I talk about totals, I am talking of the total number of sites served by the ISP, of which the majority of the total sites have only 1 or fewer v4 addresses. Albert Erdmann Network Administrator Paradise On Line Inc. From rfg at tristatelogic.com Sat May 27 03:53:32 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 27 May 2017 00:53:32 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <37601B52-B8FB-4661-89AB-21052CF28F8B@arin.net> Message-ID: <71076.1495871612@segfault.tristatelogic.com> In message <37601B52-B8FB-4661-89AB-21052CF28F8B at arin.net>, John Curran wrote: >As folks are probably aware, ARIN is quite willing to enforce SWIP >requirements in whatever manner the community deems appropriate, >we simply ask for clear direction in the form of community-developed >policy. Yes, John, I rather anticipated that you would say something along those lines. (And of course, your clarity is, as always, entirely appropriate.) Let me be crystal clear, so that no one should have any confusion about my feelings on this and/or on any other such matters. I do not in the least begrudge, in any way, either you or ARIN for failing to vigorously enforce rules which the community, in its infinite wisdom, has not given either you or ARIN a clear mandate to enforce, either in a vigorous way, or in any way, as it would seem. The fault, if there is one, lies exclusively at the feet of the community, and only the community, for it's tendency to adopt and refine rules which, when all is said and done, have no real weight behind them, and which are thus, in practice, no more meaningful that the random scratchings of chickens in the dirt. Regards, rfg From jcurran at arin.net Sat May 27 08:23:19 2017 From: jcurran at arin.net (John Curran) Date: Sat, 27 May 2017 12:23:19 +0000 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <71076.1495871612@segfault.tristatelogic.com> References: <71076.1495871612@segfault.tristatelogic.com> Message-ID: <3AA858A9-F0E8-440A-99CA-0140C3AB3B35@arin.net> On 27 May 2017, at 3:53 AM, Ronald F. Guilmette wrote: > > In message <37601B52-B8FB-4661-89AB-21052CF28F8B at arin.net>, > John Curran wrote: > >> As folks are probably aware, ARIN is quite willing to enforce SWIP >> requirements in whatever manner the community deems appropriate, >> we simply ask for clear direction in the form of community-developed >> policy. > > Yes, John, I rather anticipated that you would say something along those > lines. (And of course, your clarity is, as always, entirely appropriate.) > Let me be crystal clear, so that no one should have any confusion about > my feelings on this and/or on any other such matters. > > I do not in the least begrudge, in any way, either you or ARIN for failing > to vigorously enforce rules which the community, in its infinite wisdom, > has not given either you or ARIN a clear mandate to enforce, either in > a vigorous way, or in any way, as it would seem. The fault, if there > is one, lies exclusively at the feet of the community, and only the > community, for it's tendency to adopt and refine rules which, when all > is said and done, have no real weight behind them, and which are thus, > in practice, no more meaningful that the random scratchings of chickens > in the dirt. Let me add some additional clarity - ARIN has indeed been diligent in our enforcement of the SWIP provisions in NRPM section 4.2.3.7, but (as noted by others) that has been done at the time of allocation of additional number resources to ISPs. What ARIN has not done is proactively engaged in review and enforcement these provisions absent clear direction from the community that such is desired. If the community feels that ARIN should enforce these provisions on an on-going basis, then we will make that happen, including revocation and reissuance of number resources if such is specified. I have no doubt about ARIN?s ability to do so for all number resources in the ARIN registry, given clear policy from the community which requires such on-going enforcement. (I am in no manner advocating for such a policy change, simply making clear that the ongoing enforcement concerns are a matter of policy clarity rather than any imagined lack of ability to execute.) Thanks! /John John Curran President and CEO ARIN From rfg at tristatelogic.com Sat May 27 13:43:37 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 27 May 2017 10:43:37 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <3AA858A9-F0E8-440A-99CA-0140C3AB3B35@arin.net> Message-ID: <73108.1495907017@segfault.tristatelogic.com> In message <3AA858A9-F0E8-440A-99CA-0140C3AB3B35 at arin.net>, John Curran wrote: >(I am in no manner advocating for such a policy change, simply making clear >that the ongoing enforcement concerns are a matter of policy clarity rather >than any imagined lack of ability to execute.) Yes. I, for one, ernestly believe that ARIN could move heaven and earth, if so directed by the community, and if provided with appropriate funding to implement any such mandate. Regards, rfg From cja at daydream.com Sat May 27 14:00:31 2017 From: cja at daydream.com (Cj Aronson) Date: Sat, 27 May 2017 12:00:31 -0600 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <8A3A301D-39B5-4F81-8E2C-90E23B81919E@panix.com> <68979.1495837945@segfault.tristatelogic.com> Message-ID: Peter The draft is still on the AC's docket and the shepherds are working on it. I think it should be part of this discussion so I mentioned it so that folks could take a look. Thanks! -----Cathy {?,?} (( )) ? ? On Fri, May 26, 2017 at 5:34 PM, Peter Thimmesch wrote: > Hello Cathy, > > Yes, the was some rather heated discussion at the ARIN meeting in New > Orleans about the proposed wording in 3.6.7 Non-Responsive Point of > Contact Records. I believe, please correct me if you think otherwise, that > the consensus of opinions that spoke at the meeting were strongly against > the removing of records from public Whois. Therefore pointing someone to > consider this type of punitive action would be seemingly designed to do > what? > > What problem is trying to be solved with this proposed policy? Is it to > align the two existing policies or to create a punitive measure? > > Regards, > > Peter Thimmesch > > > On May 26, 2017, at 19:09, Cj Aronson wrote: > > Scott, > > On Fri, May 26, 2017 at 4:45 PM, Scott Leibrand > wrote: > >> On Fri, May 26, 2017 at 3:32 PM, Ronald F. Guilmette < >> rfg at tristatelogic.com> wrote: >> >>> >>> In message <8A3A301D-39B5-4F81-8E2C-90E23B81919E at panix.com>, >>> David Huberman wrote: >>> >>> >In short, there is an argument that the SWIP rules are no-op now. So to >>> answer >>> >your question directly; what do you do? Nothing. Those days are long >>> gone >>> >and ARIN has other focuses now. >>> >>> So, let me see if I understand this... >>> >>> ARIN doesn't, can't, and most probably won't either enforce the existing >>> (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be >>> drafted and/or promulgated with respect to IPv6. Is that about the size >>> of it? >>> >> >> Pretty much, unless someone comes up with a new method of enforcing SWIP >> rules. Some of the discussions with law enforcement could eventually >> result in such carrots or sticks, but no one has proposed any specifics yet. >> > > There is this draft policy that has a few "sticks" at least for > delegations to downstream ISPs. > https://www.arin.net/policy/proposals/2017_3.html > >> >> >>> >>> ----Cathy > > _______________________________________________ > 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 scottleibrand at gmail.com Sat May 27 14:44:48 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 27 May 2017 11:44:48 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <69242.1495841204@segfault.tristatelogic.com> References: <69242.1495841204@segfault.tristatelogic.com> Message-ID: On Fri, May 26, 2017 at 4:26 PM, Ronald F. Guilmette wrote: > > In message pg3Ze04k4A at mail.gmail.com> > Scott Leibrand wrote: > > >> Am I missing something? > > > >No, this proposal isn't drafting a new rule, but rather relaxing an > >existing one that mostly isn't being observed or enforced, so that people > >who follow the rules and those who don't are on a level playing field. > > I've been sitting here, reading and re-reading the above sentence, > several times, for the past few minutes, hoping that I'd be able to > read it deeply enough so that it would eventually convey to me some > not-totally-illogical thought or idea or concept, but before that > actually occurred, my head exploded. > > The fundamental problem is that I can't even begin to wrap my head > around -any- understanding of -any- alternative universe in which > having those who play by the rules and those who don't be "on a level > playing field" is either a Good Thing or a Desirable Thing. > > My utter befuddlement was furthermore raised to a higher power by > taking into account also the notion of different groups being placed > "on a level playing field" with respect to rules that... as you noted > earlier in the same sentence... aren't even being enforced. Aren't > we all, already, and by definition, "on a level playing field" with > respect to any and all rules, laws, statutes, commandments, or edicts > which are not being actively enforced? > I think you're over-interpreting my use of the level playing field metaphor. All I meant was this: If someone who likes to follow the rules, whether they're enforced or not, wants to assign IPv6 addresses to their end users, they will feel they have to SWIP all such assignments. Someone who isn't so punctilious will look at the current /64 SWIP rule, say "that is stupid", and not do so. As a result, it becomes far more costly for the rule-follower to roll out IPv6 than for the person who's ok violating the unenforced rule. It would be far better if we relax or remove any such unreasonable and unenforceable rules from the NRPM, so that those who feel they need to follow such rules are not disadvantaged relative to those who know they don't really have to and are willing to ignore them. As such, I support the stated intent of this policy for IPv6. On the topic of "what should the threshold be", I think requiring SWIPs for (non-residential) assignments is actually what we want here. If we want to pick a prefix size, then I think "more than a /56" or "/48 or larger" would be reasonable. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at linuxmagic.com Sat May 27 16:07:49 2017 From: michael at linuxmagic.com (Michael Peddemors) Date: Sat, 27 May 2017 13:07:49 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <8A3A301D-39B5-4F81-8E2C-90E23B81919E@panix.com> <68979.1495837945@segfault.tristatelogic.com> Message-ID: <1f134479-998d-30d1-2b59-5ec7eb887f30@linuxmagic.com> Last time I brought up this topic, I was informed that until the Board gets the mandate to work on enforcement, very little will be done on this. However, it wasn't clear on how that can be brought about. Of course, we are supposed to 'report it to hostmaster', but after many such reports, and seeing no effect, it makes it hard to bother with reporting it.. We see daily bad SWIP entries, entries pointing to bad or non functioning 'rwhois' servers, and without the 'stick', that is unlikely to change. We in our own way 'encourage' operators of IP Space to fix their entries, but until some form of policing is in place, I do not expect it to change much. Maybe an independent movement to 'blackhole' IP space with bad SWIP practices?? (not entirely kidding) On 17-05-26 03:45 PM, Scott Leibrand wrote: > On Fri, May 26, 2017 at 3:32 PM, Ronald F. Guilmette > > wrote: > > > In message <8A3A301D-39B5-4F81-8E2C-90E23B81919E at panix.com > >, > David Huberman > wrote: > > >In short, there is an argument that the SWIP rules are no-op now. So to answer > >your question directly; what do you do? Nothing. Those days are long gone > >and ARIN has other focuses now. > > So, let me see if I understand this... > > ARIN doesn't, can't, and most probably won't either enforce the existing > (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be > drafted and/or promulgated with respect to IPv6. Is that about the size > of it? > > > Pretty much, unless someone comes up with a new method of enforcing SWIP > rules. Some of the discussions with law enforcement could eventually > result in such carrots or sticks, but no one has proposed any specifics yet. > > > > If so, then color me perplexed. I'm not at all sure that I grasp the > reason(s) why people on this list are spending/investing time and energy > discussing and debating some new draft rule for IPv6 that also and > likewise > won't ever actually be enforced. > > > Am I missing something? > > > No, this proposal isn't drafting a new rule, but rather relaxing an > existing one that mostly isn't being observed or enforced, so that > people who follow the rules and those who don't are on a level playing > field. > > -Scott > > > > _______________________________________________ > 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. > -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From michael at linuxmagic.com Sat May 27 16:09:27 2017 From: michael at linuxmagic.com (Michael Peddemors) Date: Sat, 27 May 2017 13:09:27 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <68797.1495834581@segfault.tristatelogic.com> Message-ID: On 17-05-26 04:10 PM, hostmaster at uneedus.com wrote: > The only real "Internet Police" stick is the records needed for > additional assignments must be there before you can get more. If in > fact more is never needed because of the size of the initial allocation, > there is zero incentive to SWIP the customers, and I think this will get > worse as we move toward v6 as the main protocol on the internet. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. And even that isn't working.. we see some large providers getting new space and transfers, where existing space is not properly SWIP'ed.. but of course this isn't just an ARIN problem.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From rfg at tristatelogic.com Sat May 27 16:13:36 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 27 May 2017 13:13:36 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: Message-ID: <73821.1495916016@segfault.tristatelogic.com> In message , Scott Leibrand wrote: >On the topic of "what should the threshold be", I think requiring SWIPs for >(non-residential) assignments is actually what we want here... I'd like to take this opportunity to mention again that just the other day I requested (here) at least -some- clarity or clarification of the term of art "Residential Customer", as used in the NRPM. I did so while noting that every legal entity, human or otherwise, "resides" somewhere, even if, as often seem to be the case, the relevant "residence" is just a 4x4 inch P.O. Box, rented in the name of overnight manufactured business. I repeat and reiterate that request now. What is the definition, for purposes of the ARIN NRPM, of the term "Residential Customer" and is there any limit (for either IPv4 or IPv6) on the maximum the size of an allocation made to a "Residential Customer"? I wouldn't ask, but I do believe that I've sen cases where so-called "Residential Customers" (who later turned out to be professional snowshoe spammers) had been sub-assigned blocks as large as (IPv4) /25s. Unfortuately, given the definitional ambiguity, I have no idea if such cases do or do not conform to The Rules, as already adopted. Regards, rfg From michael at linuxmagic.com Sat May 27 16:19:30 2017 From: michael at linuxmagic.com (Michael Peddemors) Date: Sat, 27 May 2017 13:19:30 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <68979.1495837945@segfault.tristatelogic.com> Message-ID: <1194b151-cb40-2455-1963-58101dbd4c6c@linuxmagic.com> On 17-05-26 05:11 PM, hostmaster at uneedus.com wrote: > Therefore, while we discuss how many access providers are ignoring the > SWIP rules, do remember that the majority of ISP customers for IPv4 > internet access are NOT subject to the SWIP rules, since they have 1 or > less dedicated IP addresses. There is a solution to that, SWIP to the ISP 'rwhois' server(s) which have the ability to provide 'rwhois' date down to the /32. Those hosting companies that do that, are generally better netizens, and see less nefarious activity.. While the rules make it clear, that of course this isn't for every CPE device, having the owner listed, and of course that wouldn't probably fly with most european privacy laws, and it isn't meant for dynamically assigned IP space, it is considered that when you give someone a /29 or greater you are 'assigning rights' to use that block, and in this case SWIP/rwhois is the appropriate method. And of course, with the increase of cloud provider 'rent an ip by the minute' pools, it is easy to see how a case can be made not to provide 'rwhois/SWIP' for that, (records won't update fast enough, and be stale in a few minutes), we as an industry CAN apply different reputation and permissions to IP space that is properly SWIP'ed or 'rwhois', compared to space that isn't. If a person wants to 'speak' for his use of an IP resource, he/they should expect that in order to find out if he/they can speak to that usage, they should be listed in the public record as the operator of that space. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From michael at linuxmagic.com Sat May 27 16:21:12 2017 From: michael at linuxmagic.com (Michael Peddemors) Date: Sat, 27 May 2017 13:21:12 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <37601B52-B8FB-4661-89AB-21052CF28F8B@arin.net> References: <68979.1495837945@segfault.tristatelogic.com> <61220AB4-1F3D-4082-A380-2943117A91F0@addrex.net> <37601B52-B8FB-4661-89AB-21052CF28F8B@arin.net> Message-ID: <1a95c0ab-558a-7620-96bd-dc82a8a9b99d@linuxmagic.com> On 17-05-26 06:47 PM, John Curran wrote: > Indeed. > > As folks are probably aware, ARIN is quite willing to enforce SWIP > requirements in whatever manner the community deems appropriate, > we simply ask for clear direction in the form of community-developed > policy. > > Thanks! > /John > > John Curran > President and CEO > ARIN Could you give an example of what would mandate a 'clear direction' and what form the 'policy' would take in order for ARIN to start enforcing? This might help start the process? -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From michael at linuxmagic.com Sat May 27 16:40:08 2017 From: michael at linuxmagic.com (Michael Peddemors) Date: Sat, 27 May 2017 13:40:08 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: References: <8A3A301D-39B5-4F81-8E2C-90E23B81919E@panix.com> <68979.1495837945@segfault.tristatelogic.com> Message-ID: <0a860fd3-1673-0be0-d0dd-c1228cfce989@linuxmagic.com> Cathy, While this is a nice step, and indicates a move forward towards this.. (Wish I just had more time to contribute..) It would be nice that somehow we find a way to 'assist' ARIN, in a public manner, and have it adopted in policy in some form. We have had several ppl who 'see' on a regular basis bad/poor SWIP records and practices. Proposal Idea: Allow the community at large to 'register' complaints, but instead of having it sent to what for all intents and purposes can seem like a an opaque resolution process, have such complaints registered as publicly searchable 'tickets'. Eg.. ABC Company operates a /16 assigned by ARIN, which lists a redirection to a 'rwhois' server, which is currently not responding, or non-existant. Rather than ARIN having to search those out (while it can be automated of course, a simple script can attempt to probe the listed 'rwhois' servers) which may take resources ARIN doesn't have at it's disposal, allow a ticket to be filed by the internet community, and all tickets and their investigation/resolution status can be viewed. Eg.. Ticket Submitted By: Ticket Submitted Date: Ticket Class: Non-Responsive RWhois Server in SWIP record Ticket Status: Unconfirmed Arin Confirmation Date: First Notification to Owner Sent: Owner Response: Expected Resolution Date: You get my drift.. that way if the information is public, not only will this encourage owners to update the information (shame them) but will give the community an idea of whether the actual resolution process is ongoing, and an idea that is will culminate in actual action. While I have no doubt that ARIN takes seriously all reports sent to them, we have no way of knowing if it simply cannot be addressed due to limited resources, or slipped through the cracks, or if ARIN actually is hard at work solving the problem.. On 17-05-27 11:00 AM, Cj Aronson wrote: > Peter > > The draft is still on the AC's docket and the shepherds are working on > it. I think it should be part of this discussion so I mentioned it so > that folks could take a look. > > Thanks! > -----Cathy > > > {?,?} > (( )) > ? ? > > On Fri, May 26, 2017 at 5:34 PM, Peter Thimmesch > > wrote: > > Hello Cathy, > > Yes, the was some rather heated discussion at the ARIN meeting in > New Orleans about the proposed wording in 3.6.7 Non-Responsive Point > of Contact Records. I believe, please correct me if you think > otherwise, that the consensus of opinions that spoke at the meeting > were strongly against the removing of records from public Whois. > Therefore pointing someone to consider this type of punitive action > would be seemingly designed to do what? > > What problem is trying to be solved with this proposed policy? Is it > to align the two existing policies or to create a punitive measure? > > Regards, > > Peter Thimmesch > > > On May 26, 2017, at 19:09, Cj Aronson > wrote: > >> Scott, >> >> On Fri, May 26, 2017 at 4:45 PM, Scott Leibrand >> > wrote: >> >> On Fri, May 26, 2017 at 3:32 PM, Ronald F. Guilmette >> > wrote: >> >> >> In message <8A3A301D-39B5-4F81-8E2C-90E23B81919E at panix.com >> >, >> David Huberman > > wrote: >> >> >In short, there is an argument that the SWIP rules are no-op now. So to answer >> >your question directly; what do you do? Nothing. Those days are long gone >> >and ARIN has other focuses now. >> >> So, let me see if I understand this... >> >> ARIN doesn't, can't, and most probably won't either >> enforce the existing >> (IPv4) SWIP rules, nor, for that matter, any new SWIP >> rules that may be >> drafted and/or promulgated with respect to IPv6. Is that >> about the size >> of it? >> >> >> Pretty much, unless someone comes up with a new method of >> enforcing SWIP rules. Some of the discussions with law >> enforcement could eventually result in such carrots or sticks, >> but no one has proposed any specifics yet. >> >> >> There is this draft policy that has a few "sticks" at least for >> delegations to downstream ISPs. >> https://www.arin.net/policy/proposals/2017_3.html >> >> >> >> >> >> ----Cathy >> _______________________________________________ >> 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. > -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From rfg at tristatelogic.com Sat May 27 17:04:22 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 27 May 2017 14:04:22 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <1f134479-998d-30d1-2b59-5ec7eb887f30@linuxmagic.com> Message-ID: <73988.1495919062@segfault.tristatelogic.com> In message <1f134479-998d-30d1-2b59-5ec7eb887f30 at linuxmagic.com>, Michael Peddemors wrote: >Of course, we are supposed to 'report it to hostmaster', but after many >such reports, and seeing no effect, it makes it hard to bother with >reporting it.. Yes. Statistically speaking, it has appeared to me that approximately 98 times out of a hundred, any report regarding either an utterly non- functioning rwhois server and/or big swaths of spammer-infested IPv4 space where the IP blocks are clearly and provably "live" (and spewing spam) and where the relevant rwhois server simply returns -no- information, such reports are greeted with abject silence and no change to anything whatsoever, even when allowed to percolate for a week or more. And indeed, the problem is getting worse. The latest, biggest, and most disappointing such failure is for the entirity of 38.0.0.0/8 aka rwhois://rwhois.cogentco.com:4321 which appears to have been recently emptied of -all- information, with the exception of a single common one-line greeting banner. But that is just one example. If pressed, I'm quite sure that I could cite innumerable others in short order. I come across these broken (or deliberately disabled) rwhois servers every day now, and often multiple times each day. (Sometimes, I can't help but think to myself that the relevant providers might just as well hang big signs around their necks saying "Yes, we know that we are harboring snowshoe spammers, but they are paying us not to let on to anyone who they are.") >We see daily bad SWIP entries, entries pointing to bad or non >functioning 'rwhois' servers, and without the 'stick', that is unlikely >to change. Quite so. >Maybe an independent movement to 'blackhole' IP space with bad SWIP >practices?? (not entirely kidding) It isn't always done with malice, and is, in my opinion, just as often done out of carelessness, laziness, or a simple failure, on the part of the lowest-level operational worker bees to understand or even be aware of the ARIN requirements. Over time, at a lot of these places, management changes, ownership changes, and worker bees come and go or are swapped out for newer ones, and the internal company memo about the ARIN requirements gets lost in the shuffle and ends up in the dumpster out back. There are never any downside consequences, and thus, the overworked and underpaid worker bees focus their daily efforts on keeping the network running and all of the customer machines up, just as we all would, if placed in similar positions. I might be tempted to suggest that perhaps John C. and his team might possibly be able to render some useful service with respect to this large and growing problem, via something that would fall well short of any kind of formal "enforcement" action... e.g. just sending a polite/ friendly email to the relevant provider in each case, asking them to please consider turning their rwhois servers back on... but I'm afraid that there would likely be resistance, both in the community and from ARIN itself, to having ARIN do even that sort of minimalist thing, because ARIN has not been explicitly tasked to do it, formally or otherwise, by the community. On the other hand, if ARIN -were- ever so tasked, they wouldn't need to go out searching for providers with broken or non-functioning rwhois servers, as I could, and would, gladly, email them a daily stream of reports of exactly such providers. (Remarkable as it may seem to some, real-world experience indicates that there is a dramaticaally high degree of intersection/overlap between the set of providers that, on any given day, can be shown to be hosting snowshoe spammers, and the set of providers that, on that same day, are demonstratably failing to run a functioning or useful rwhois server or to use WHOIS/SWIPs to properly document their sub-allocations. I know what you're thinking... "Gee! Who woulda thunk it?"... Right? :-) Regards, rfg From daveid at panix.com Sat May 27 17:27:08 2017 From: daveid at panix.com (David Huberman) Date: Sat, 27 May 2017 17:27:08 -0400 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <73821.1495916016@segfault.tristatelogic.com> References: <73821.1495916016@segfault.tristatelogic.com> Message-ID: It's hidden in the definition section up top: https://www.arin.net/policy/nrpm.html#two13 Sent from my iPhone > On May 27, 2017, at 4:13 PM, Ronald F. Guilmette wrote: > > > In message , > Scott Leibrand wrote: > >> On the topic of "what should the threshold be", I think requiring SWIPs for >> (non-residential) assignments is actually what we want here... > > I'd like to take this opportunity to mention again that just the other > day I requested (here) at least -some- clarity or clarification of the > term of art "Residential Customer", as used in the NRPM. I did so while > noting that every legal entity, human or otherwise, "resides" somewhere, > even if, as often seem to be the case, the relevant "residence" is just > a 4x4 inch P.O. Box, rented in the name of overnight manufactured > business. > > I repeat and reiterate that request now. What is the definition, for > purposes of the ARIN NRPM, of the term "Residential Customer" and is > there any limit (for either IPv4 or IPv6) on the maximum the size of > an allocation made to a "Residential Customer"? > > I wouldn't ask, but I do believe that I've sen cases where so-called > "Residential Customers" (who later turned out to be professional > snowshoe spammers) had been sub-assigned blocks as large as (IPv4) /25s. > > Unfortuately, given the definitional ambiguity, I have no idea if such > cases do or do not conform to The Rules, as already adopted. > > > Regards, > rfg > _______________________________________________ > 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 rfg at tristatelogic.com Sat May 27 17:55:50 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 27 May 2017 14:55:50 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <1194b151-cb40-2455-1963-58101dbd4c6c@linuxmagic.com> Message-ID: <74131.1495922150@segfault.tristatelogic.com> In message <1194b151-cb40-2455-1963-58101dbd4c6c at linuxmagic.com>, Michael Peddemors wrote: >... >There is a solution to that, SWIP to the ISP 'rwhois' server(s) which >have the ability to provide 'rwhois' date down to the /32. >... >While the rules make it clear, that of course this isn't for every CPE >device, having the owner listed, and of course that wouldn't probably >fly with most european privacy laws... Just FYI -- That's rubbish. When it comes down to brass tacks and real-world pragmatics, the europeans, despite all of their bluster and bravado about "personal privacy", are very nearly as pragmatic as we are. For example, it is trivially easy, in most cases to get meaningful and useful WHOIS data for .EU and .DE domain names, even when those are allegedly registered to "natural persons". The europeans manage to mentally square this with their much ballyhooed emphasis on personal privacy via the fig leaf of hiding the data behind a captcha in each case. (I know, because not that long ago I was easily able to obtain the alleged name of an alleged German citizen who had allegedly registered a particular .DE domain name that was being used to distribute jihadi videos.) The same pragmatic considerations have also, thankfully, taken precedence within the context of the whole "EU-US Privacy Shield" bruhaha: http://europa.eu/rapid/press-release_IP-16-216_en.htm You can be sure that any time you see the terms "ombudsperson" and/or "robust enforcement" within any governmentally-issued statement, such as the one just above, that it is all a PR smokescreen being used to delude the public at large into beliveing anything other than the truth, which is that the status quo is being preserved. And indeed as the New York Times reported: https://www.nytimes.com/2016/02/03/technology/us-europe-safe-harbor-data-deal.html "European officials on Tuesday agreed to a deal with the United States that would let Google, Amazon and thousands of other businesses continue moving people's digital data, including social media posts and financial information, back and forth across the Atlantic..." My only point is that if push ever came to shove, and if ARIN ever made a rule stating that (for all ARIN IP space) rwhois records for IPv4 space, down to the /32, would henceforth be required, even if they explicitly named "natural persons", then the europeans would grumble and pound their fists on the table, but at the end of the day they would fall into line and permit it, all while noting their strenuous objections, for the record, of course. But of course, this is all irrelevant, since ARIN shall certainly never make any such rule, helpful though such a thing might be, e.g. to law enforcement, to spammer hunters, and even to those ordinary consumers who are daily defrauded out of their hard-earned cash by this month's crop of fast-talking hucksters with slick web sites. >If a person wants to 'speak' for his use of an IP resource, he/they >should expect that in order to find out if he/they can speak to that >usage, they should be listed in the public record as the operator of >that space. Yes. The analogy I already put forward is the vehicle license plate. If you're going to drive around on streets that -the public- paid for, then you gotta have one, and your petty and personal gripes about your "loss of privacy" be damned. But this is the point in the conversation where some provider(s) always pipes up and says "Yeabut -we- fully paid for -our- infrastructure, so it isn't a ``public'' resource that's being used, and thus, nobody has a right to tell us what to do, na na na na na!" Even leaving aside the fact that, as a matter of historical record, all these same folks have effectively built their businesses and perofitability on the backs of the original *government funded* Arpanet research, it should not and cannot escape anyone's notice or attention that the Internet doesn't exactly qualify as a ``niche'' industry that only affects a small segment of society anymore. Thus, at some point there may come a day when many such parochial and private interests may no longer be sustainable, e.g. in the face of the ongoing, growing, and daily festival of hacking, cracking, and fraud that has become the modern Internet. Regards, rfg From rfg at tristatelogic.com Sat May 27 19:58:22 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 27 May 2017 16:58:22 -0700 Subject: [arin-ppml] IPv4 SWIP requirements (?) In-Reply-To: <0a860fd3-1673-0be0-d0dd-c1228cfce989@linuxmagic.com> Message-ID: <74463.1495929502@segfault.tristatelogic.com> In message <0a860fd3-1673-0be0-d0dd-c1228cfce989 at linuxmagic.com>, Michael Peddemors wrote: >Allow the community at large to 'register' complaints, but instead of >having it sent to what for all intents and purposes can seem like a an >opaque resolution process, have such complaints registered as publicly >searchable 'tickets'. I, for one, would vigorously come out in support of this, *if* I didn't think that my doing so would immediately, inevitably, and irrevocably doom this simple proposal to abject failure, if not also to near universal condemnation. (1/2 :-) But seriously, as already noted by others, ARIN currently labors under a fundamental lack of ability or means to meaningfully enforce various existing and community-approved regulations, as already formalized and codified in the NRPM. Given that, it would seem to be a rather obviously pointless exercise in silliness -either- for people to message ARIN to request it to open "cases" or "tickets" -or- for ARIN to dedicate any staff time or energy into researching the particulars of any such case or tickets when, at the end of the day, they have no community-approved means to do anything about it, regardless of the outcome of any such investigation(s). In similar situtations, where the law and its enforcement become so radically disconnected that the law itself falls into disrepute and ridicule, there are usually one of two outcomes, i.e. either (a) vigilantism or (b) public naming and shaming (or sometimes both). I suspect that on this list, at least, there would be general agreement with the proposition that vigilantism is actually -not- the preferable outcome in this case. In contrast however, the general idea of having a place where reports which are sent to ARIN regarding possible violations of NPRM regulations would be on public display would seem to have a number of advantages, both for the community and for ARIN. Firstly, it would arguably relieve and absolve ARIN from responsibility for either the investigation of such reports, and/or from the responsibility, legal and otherwise, which might otherwise accrue to ARIN as a result of its publication of findings and/or its action or inaction with regards to any given case. Members of the ARIN community, and of the worldwide Internet user base generally, including myself, can and do already investigate many issues that often touch on clear and apparent NRPM violations, and we simply lack a proper forum to share the resulting information with all interested parties. (I suspect that everyone will agree that the PPML is -not- actually the best or most appropriate place to document the failings of this or that specific ARIN customer.) If a public blog, or forum, or some such thing (which would be searchable by IP address, or CIDR, or ASN, or WHOIS handle) was created by ARIN, made a part of the ARIN web site, and then opened for public submissions relating to purported NRPM violations, it seems entirely likely to me that ARIN would then, and at virtually no cost, benefit from obtaining relevant data about specific trouble spots from an entire planet's worth of investigators... investigators who would then have a means to coordinate, and to share and exchange information about such trouble spots in an open forum. And this kind of information, from outside investigators, might in some cases rival or even surpass what ARIN might be able to discover, via its own internal investigations. (And in any case, it would certainly cost less, as ARIN would be getting the information for free.) Secondly, the community would benefit from more open communications about the various direct ARIN customers who are simply not following the community-endorsed (NRPM) rules. Exactly such open communications, even when not leading to formal ARIN actions (as I expect they wouldn't in virtually all cases), would tend to have the effects of public naming and shameing of the scofflaws, thus encouraging compliance with NRPM mandates without resort to formal ARIN enforcement and/or its attendant potential for sticky, annoying, time-consuming and expensive legal entanglements. In short, this seems like a win-win-win. ARIN wins by getting off the hook for investigating and/or "actioning" NRPM violations that it doesn't really have either the clear mandate or the funding to either investigate or action anyway, and the community gets more transparency, a kinder, gentler, and less expensive way to disipline the scofflaws, along with a smaller legal liability footprint for ARIN.[1] And lastly, troublemakers like me get a place to vent spleen and document the specific non-NRPM-conformant actions of various ARIN direct and indirect customers... politely, of course... while contributing to the community's (and ARIN's) knowledge of who is, and who isn't following the rules. As a friend of mine once said "The only thing wrong with that idea is that *I* didn't think of it first." Regards, rfg P.S. In addition to all of the other benefits noted above, the creation of an open forum, were reports regarding NRPM violations could be publically lodged, would benefit ARIN by being a clear refutation of the criticisms that have occasionally been leveled at it, here and elsewhere, to the effect that its internal processes are opaque, inscrutable, and non-transparent, either deliberately or otherwise. What could be more transparent than an open public forum? Note that I am -not- -not- -not- suggesting that any member of ARIN staff would be or should be encouraged to -participate- in or on any such hypothetical forum. Nor am I suggesting for one second that ARIN should deviate in the slightest from its historical and appropriate tight-lipped approach to any and all matters that may implicate actual enforcement actions, somewhere down the road. But even without any active participation by any ARIN staff, an open public forum for the open publication and sharing of information about NRPM violations would signal to the world ARIN's commitment to transparency, and specifically, transparency in the service of the ARIN community and the rules it has adopted, democratically, via the consent of the governed. ========== [1] Note that just as with all ISPs and all operators of open web site forums, ARIN would have blanket and absolute protection from legal liability for anything that anyone outside of ARIN might post to any such hypothetical blog, under the unambiguous and courtroom-tested provisions of 47 USC 230(c)(1). From hostmaster at uneedus.com Sat May 27 21:00:32 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Sat, 27 May 2017 21:00:32 -0400 (EDT) Subject: [arin-ppml] Defining Residential Customers in Policy Manual In-Reply-To: <73821.1495916016@segfault.tristatelogic.com> References: <73821.1495916016@segfault.tristatelogic.com> Message-ID: I dont think that ARIN has actually made any attempt to define "Residential Customer", but the term seems to imply the person, not the place. For example, If I live at my business, I think I could still be a "Residential Customer". I know under the old days of landline telephone that private executive telephone lines were billed at the residential rate in the tariff, and were not "Business Lines". If you think it should be defined, I suggest thinking of a suitable definition and proposing it as an addition to the Policy Manual. This is the process we have in place to fix things. My largest residential customer as far as total address space use is a /24 of v4, and they have controlled this space since before ARIN. This is legacy space and every machine gets a routable address. Unlike others discussed, I do know they keep their POC up to date. I see nothing in the policy manual that would prohibit a residential subscriber (or anyone else) from holding any amount of address space that can be justified by actual use. If one decided to assign routeable IP's to every device in a residence rather than NAT, one could burn thru a /24 very easy in many households. I have customers that I have to set their mask to /22 or more because they burn up all the leases in a /24 of RFC 1918 space on their wireless router. Albert Erdmann Network Administrator Paradise On Line Inc. On Sat, 27 May 2017, Ronald F. Guilmette wrote: > > In message , > Scott Leibrand wrote: > >> On the topic of "what should the threshold be", I think requiring SWIPs for >> (non-residential) assignments is actually what we want here... > > I'd like to take this opportunity to mention again that just the other > day I requested (here) at least -some- clarity or clarification of the > term of art "Residential Customer", as used in the NRPM. I did so while > noting that every legal entity, human or otherwise, "resides" somewhere, > even if, as often seem to be the case, the relevant "residence" is just > a 4x4 inch P.O. Box, rented in the name of overnight manufactured > business. > > I repeat and reiterate that request now. What is the definition, for > purposes of the ARIN NRPM, of the term "Residential Customer" and is > there any limit (for either IPv4 or IPv6) on the maximum the size of > an allocation made to a "Residential Customer"? > > I wouldn't ask, but I do believe that I've sen cases where so-called > "Residential Customers" (who later turned out to be professional > snowshoe spammers) had been sub-assigned blocks as large as (IPv4) /25s. > > Unfortuately, given the definitional ambiguity, I have no idea if such > cases do or do not conform to The Rules, as already adopted. > > > Regards, > rfg > _______________________________________________ > 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 rfg at tristatelogic.com Sat May 27 22:55:35 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 27 May 2017 19:55:35 -0700 Subject: [arin-ppml] "Residential Customer" by examples In-Reply-To: Message-ID: <75048.1495940135@segfault.tristatelogic.com> In message , David Huberman wrote: >It's hidden in the definition section up top: > >https://www.arin.net/policy/nrpm.html#two13 I do apologize for being so dense and/or so pedantic, but I'm still rather entirely unclear on the precise meaning and appropriate interpretation of the term "Residential Customer" as allegedly defined in NRPM section 2.13 and as referenced in NRPM sections 4.2.3.7.3.2 and 6.5.5.3.1. Perhaps David or others can help alleviate my confusion by way of a couple of specific examples... Let's take the dual cases of 69.162.77.192/29 (NET-69-162-77-192-1) and also 69.162.115.240/28 (NET-69-162-115-240-1). Now, with respect to these two specific cases, I'll be more than happy to concede that the specific East Bloc cybercriminal who has been using both of these blocks as his base of operations for some months now... as he merrily goes about his daily acivities of hacking machines, spamming, and spreading malware... probably -does- have a ``residence'' someplace, most likely in Moscow, according to my research, but perhaps even in Riga, Latvia, as suggested by the ARIN WHOIS record. He may even be sitting in that residence right now, as we speak, sipping on a Jolt Cola, and giggling to himself as he sits comfortably in his dirty t-shirt, shorts, and flip-flops. (It's warning up now, this time of year, even in Moscow.) So, given that this guy undoubtedly ``resides'' *somewhere* it seems that it could easily be argued that this cybercrook technically qualifies as a "Residential" customer. And I have no reason to doubt at all that he may be, and most probably is actually accessing his servers... and thus, arguably, "receiving service", as per NRPM 2.13... at his residence in Moscow, or Riga, or wherever. Thus, any lawyer worth his salt could and would argue that this guy qualifies... at least under a somewhat contorted reading of NRPM 2.13... as a "Residential Customer". But that all having been said, from where I am sitting, traceroutes into the middles of these two IPv4 blocks appear to me to dead-end someplace within a data center in Dallas, Texas. So, you know, I'll be the first to admit that I do make mistakes, and maybe I'm just misinterpreting the traceroute data, and maybe these two IPv4 assignments really do dead-end at a nice summer dacha in or on the outskirts of Riga. And in that case, I'll just beg forgiveness of everyone here and apply for that remedial traceroute reading course that I saw advertised on TV. On the other hand, if in fact what I seem to be seeing in the traceroutes is correct, I can imagine yet another scenario that would easily explain the known facts of this case. It is not utterly beyond the realm of possibility that this fellow, this cybercriminal from Riga (or, more likely, Moscow), has acually managed to make his way to the United States, and thence to Dallas, Texas, and then, with the help of a folding cot, a sleeping bag and a little portable gas stove, the guy could have easily taken up residence within some comfortable corner of the very same Dallas data center where the traceroutes seem to lead. In this case also, a clever attorney would argue.... and I personally would have to conceed... that under one possible interpretation of NRPM 2.13 the cybercrook in question *does* qualify as a "Residential Customer". (Although in this case, one might be forgiven for faulting Limestone Networks for having incorrectly listed "Riga, Latvia" as the publically-accessible part of the fellow's residence address, rather than, you know, Dallas, Texas, which would arguably have been rather more accurate.) I'm quite sure that some of my inability to understand this all arises from my own ignorance and my own limited and now-antiquated understanding of commercial networking and connectivity provisioning. I do confess that I've failed to keep up with all of the technical innovations of the past few years, and as a result I still cling to a rather old-fashioned mental image of a "residential customer" as being someone sitting in a house or an apartment within a residential neighborhood, and out at the end of some pair of copper wires. (Silly, I know.) And of course, this antiquated mental image I have of the traditional "Norman Rockwell" residential customer, just doesn't fit well anymore with the likes of more modern service providers, such as Limestone Networks, which is apparently able to provide (and actually providing) "residential service" to Riga, Latvia from its headquarters in Dallas, Texas. Anyway, I really am sheepishly apologetic to everyone here for my difficulty in understanding these new sorts of "residential" service arrangements, but in my own defense I'd just like everyone to note that my ability (or rather inability) to wrap my head around this kind of new-style residential service provisioning hasn't been helped any by what I see on Limestone's corporate home page, which mentions only "Dedicated Servers", "Cloud Solutions", and "Colocation Services", but neglects to mention the company's residential service offerings within the Baltic States. Perhaps if they update their home page so as to mention those residential offerings also, I and others will be better able to understand how they came to have "Private Customer" ARIN SWIPs in Riga, Latvia while providing service to Russian cybercriminals via the very same ARIN allocations. Regards, rfg P.S. This particular case probably wouldn't even have caught my eye or attention had it not been for the fact that the specific Russian cyber- criminal whose identity is being so effectively hidden behind the aforementioned ARIN "Private Customer" SWIPs has denominated all of the prices for all of the fradulent crap he's selling on his fradulent web sites in U.S. dollars, and the fact that these sites are all written in impeccable American Engish. In short, this particular cybercrook is *not* targeting Zimbabweans or Singaporeans. He's targeting Americans. (And I happen to be one of those, just as, presumably, the officers, directors, and employees of Limestone Networks are, even if they are also Texans.) That this cybercrook is able to specifically target Americans, apparently entirely, or at least arguably, while staying entirely "within the rules" (of ARIN) is, I think, a rather entirely disgusting example, both of the clear and apparent gaping loopholes in the system, and of the willingness and ability of various providers within the ARIN region... and in the U.S. in particular... to deftly skirt at least the intent of the rules, and perhaps even the letter of them, and thus to profit, even if only indirectly, from the criminal schemes and frauds of East Bloc cybercrooks, even and especially those who target the providers' fellow countrymen, in part by providing to these cybercrooks the specific commodity that the cybercrooks value most highly: anonymity. This commodity is -not- being provided to the cybercrooks gratis of course. We live in America, after all... land of the free and home of profit motive. Thus, as is customary, both in business and in crime the world over, the providers are providing the anonymity service in exchange for their agreed- upon piece of the pie. P.P.S. It is my sincere and certain hope that nobody, and least of all ARIN, will do anything which would in any way disturb, delete, or alter either of the two SWIPs mentioned above as a result of this posting. I am not quite finished studying the activities of the inhabitants therein just yet, and thus have no desire to see them immediately disturbed. Thankfully, given that ARIN has no clear community mandate to do so, I can have utter confidence in ARIN's discression in this matter, especially given that Limestone Networks seems unlikely to be requesting new allocations within the immediate future. From hostmaster at uneedus.com Sun May 28 09:24:41 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Sun, 28 May 2017 09:24:41 -0400 (EDT) Subject: [arin-ppml] "Residential Customer" by examples In-Reply-To: <75048.1495940135@segfault.tristatelogic.com> References: <75048.1495940135@segfault.tristatelogic.com> Message-ID: Well, assuming everything is legit, maybe those last stars on the traceroute belong to a point to point link between Dallas and Riga :) Of course the more likely course is that this block points to a server in that datacenter, and by the definition is not a "Residential Customer". The only realistic option is to blackhole those blocks, and/or the allocations to that upstream operator. Having learned that a definition does exist, I guess I am supposed to notify the one IPv6 provider who has registered my assignments in SWIP to take down the privacy protection for my /48 assignment, as the policy manual would likely consider my SSH'ing to business hosts to be not consistent with a "Residential Customer". As for my other upstream provider and their /48 assignment, there is no SWIP record to change, as they have never registered the assignment. Just as a note toward 2017-5: Since I only have a single IPv4 address at home from each upstream, unlike our Riga "friend", no SWIP requirement exists in my case. However, after looking over the rest of the definitions in that section at 2.15 Provider Assignment Unit, it appears that ARIN recommends that I receive a /48 for each site. However as discussed before, these "minimum" assignments trigger a SWIP requirement. Maybe since 2.15 suggests a minimum IPv6 site assignment of /48, my proposal should be amended to match this by changing "more than a /60" to "more than a /48". Albert Erdmann Network Administrator Paradise On Line Inc. On Sat, 27 May 2017, Ronald F. Guilmette wrote: > > In message , > David Huberman wrote: > >> It's hidden in the definition section up top: >> >> https://www.arin.net/policy/nrpm.html#two13 > > I do apologize for being so dense and/or so pedantic, but I'm still rather > entirely unclear on the precise meaning and appropriate interpretation of > the term "Residential Customer" as allegedly defined in NRPM section 2.13 > and as referenced in NRPM sections 4.2.3.7.3.2 and 6.5.5.3.1. > > Perhaps David or others can help alleviate my confusion by way of a couple > of specific examples... > > Let's take the dual cases of 69.162.77.192/29 (NET-69-162-77-192-1) and > also 69.162.115.240/28 (NET-69-162-115-240-1). > > Now, with respect to these two specific cases, I'll be more than happy > to concede that the specific East Bloc cybercriminal who has been using > both of these blocks as his base of operations for some months now... as he > merrily goes about his daily acivities of hacking machines, spamming, and > spreading malware... probably -does- have a ``residence'' someplace, > most likely in Moscow, according to my research, but perhaps even in > Riga, Latvia, as suggested by the ARIN WHOIS record. He may even be > sitting in that residence right now, as we speak, sipping on a Jolt Cola, > and giggling to himself as he sits comfortably in his dirty t-shirt, > shorts, and flip-flops. (It's warning up now, this time of year, even > in Moscow.) > > So, given that this guy undoubtedly ``resides'' *somewhere* it seems that > it could easily be argued that this cybercrook technically qualifies as > a "Residential" customer. And I have no reason to doubt at all that he > may be, and most probably is actually accessing his servers... and thus, > arguably, "receiving service", as per NRPM 2.13... at his residence in > Moscow, or Riga, or wherever. Thus, any lawyer worth his salt could and > would argue that this guy qualifies... at least under a somewhat contorted > reading of NRPM 2.13... as a "Residential Customer". > > But that all having been said, from where I am sitting, traceroutes into > the middles of these two IPv4 blocks appear to me to dead-end someplace > within a data center in Dallas, Texas. > > So, you know, I'll be the first to admit that I do make mistakes, and > maybe I'm just misinterpreting the traceroute data, and maybe these > two IPv4 assignments really do dead-end at a nice summer dacha in or > on the outskirts of Riga. And in that case, I'll just beg forgiveness > of everyone here and apply for that remedial traceroute reading course > that I saw advertised on TV. > > On the other hand, if in fact what I seem to be seeing in the traceroutes > is correct, I can imagine yet another scenario that would easily explain the > known facts of this case. > > It is not utterly beyond the realm of possibility that this fellow, this > cybercriminal from Riga (or, more likely, Moscow), has acually managed to > make his way to the United States, and thence to Dallas, Texas, and then, > with the help of a folding cot, a sleeping bag and a little portable gas > stove, the guy could have easily taken up residence within some comfortable > corner of the very same Dallas data center where the traceroutes seem to > lead. > > In this case also, a clever attorney would argue.... and I personally would > have to conceed... that under one possible interpretation of NRPM 2.13 the > cybercrook in question *does* qualify as a "Residential Customer". (Although > in this case, one might be forgiven for faulting Limestone Networks for > having incorrectly listed "Riga, Latvia" as the publically-accessible part > of the fellow's residence address, rather than, you know, Dallas, Texas, > which would arguably have been rather more accurate.) > > I'm quite sure that some of my inability to understand this all arises > from my own ignorance and my own limited and now-antiquated understanding > of commercial networking and connectivity provisioning. I do confess that > I've failed to keep up with all of the technical innovations of the past > few years, and as a result I still cling to a rather old-fashioned mental > image of a "residential customer" as being someone sitting in a house or > an apartment within a residential neighborhood, and out at the end of some > pair of copper wires. (Silly, I know.) > > And of course, this antiquated mental image I have of the traditional > "Norman Rockwell" residential customer, just doesn't fit well anymore > with the likes of more modern service providers, such as Limestone Networks, > which is apparently able to provide (and actually providing) "residential > service" to Riga, Latvia from its headquarters in Dallas, Texas. > > Anyway, I really am sheepishly apologetic to everyone here for my difficulty > in understanding these new sorts of "residential" service arrangements, but > in my own defense I'd just like everyone to note that my ability (or rather > inability) to wrap my head around this kind of new-style residential service > provisioning hasn't been helped any by what I see on Limestone's corporate > home page, which mentions only "Dedicated Servers", "Cloud Solutions", and > "Colocation Services", but neglects to mention the company's residential > service offerings within the Baltic States. > > Perhaps if they update their home page so as to mention those residential > offerings also, I and others will be better able to understand how they > came to have "Private Customer" ARIN SWIPs in Riga, Latvia while providing > service to Russian cybercriminals via the very same ARIN allocations. > > > Regards, > rfg > > > P.S. This particular case probably wouldn't even have caught my eye or > attention had it not been for the fact that the specific Russian cyber- > criminal whose identity is being so effectively hidden behind the > aforementioned ARIN "Private Customer" SWIPs has denominated all of the > prices for all of the fradulent crap he's selling on his fradulent web > sites in U.S. dollars, and the fact that these sites are all written in > impeccable American Engish. > > In short, this particular cybercrook is *not* targeting Zimbabweans or > Singaporeans. He's targeting Americans. (And I happen to be one of > those, just as, presumably, the officers, directors, and employees of > Limestone Networks are, even if they are also Texans.) > > That this cybercrook is able to specifically target Americans, apparently > entirely, or at least arguably, while staying entirely "within the rules" > (of ARIN) is, I think, a rather entirely disgusting example, both of the > clear and apparent gaping loopholes in the system, and of the willingness > and ability of various providers within the ARIN region... and in the U.S. > in particular... to deftly skirt at least the intent of the rules, and > perhaps even the letter of them, and thus to profit, even if only indirectly, > from the criminal schemes and frauds of East Bloc cybercrooks, even and > especially those who target the providers' fellow countrymen, in part by > providing to these cybercrooks the specific commodity that the cybercrooks > value most highly: anonymity. > > This commodity is -not- being provided to the cybercrooks gratis of course. > We live in America, after all... land of the free and home of profit motive. > Thus, as is customary, both in business and in crime the world over, the > providers are providing the anonymity service in exchange for their agreed- > upon piece of the pie. > > > P.P.S. It is my sincere and certain hope that nobody, and least of all > ARIN, will do anything which would in any way disturb, delete, or alter > either of the two SWIPs mentioned above as a result of this posting. I am > not quite finished studying the activities of the inhabitants therein just > yet, and thus have no desire to see them immediately disturbed. Thankfully, > given that ARIN has no clear community mandate to do so, I can have utter > confidence in ARIN's discression in this matter, especially given that > Limestone Networks seems unlikely to be requesting new allocations within > the immediate future. > _______________________________________________ > 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 Andrew.C.Hadenfeldt at windstream.com Mon May 29 23:56:29 2017 From: Andrew.C.Hadenfeldt at windstream.com (Hadenfeldt, Andrew C) Date: Tue, 30 May 2017 03:56:29 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> Message-ID: <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> Oppose as written, +1 on the points below (leave /29 alone, and would prefer to see /56 rather than /60) -Andy From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Tuesday, May 23, 2017 2:02 PM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On Tue, May 23, 2017 at 2:35 PM, ARIN > wrote: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Policy statement: Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to "more than a /28". Hello, In my opinion... Leave /29 alone or change it to "more than a single IP address." In these days of IPv4 shortage, substantial networks sit behind small blocks of public addresses. These networks should be documented with reachable POCs lest the anti-spam/virus/malware folks slam down /24 filters for lack of information about how misbehaving networks are partitioned. Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to "more than a /60". Change this to "more than a /56." Service providers should NOT be assigning /64's to end users. If you're doing that, you're doing it wrong. An IPv6 customer should be able to have more than one /64 subnet without resorting to NAT so /60 should be the absolute minimum end-user assignment, equivalent for all intents and purposes to an IPv4 /32. If we then want "equivalence" to the /29 policy so that individuals with the minimum and near-minimum assignment do not need to be SWIPed, it makes sense to move the next subnetting level up. In IPv6, assignment is strongly recommended on nibble boundaries, so that means /56. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oroberts at bell.ca Tue May 30 09:12:03 2017 From: oroberts at bell.ca (Roberts, Orin) Date: Tue, 30 May 2017 13:12:03 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> Message-ID: <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> Hello all, I am avidly following this discussion and based on my daily observances (daily swips /subnets ), I would say Andy is closest to being practical. Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents total chaos. With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a /56 OR LARGER NETWORK assignment be swiped. That would still leave /60 to /64 assignments as minimum assignment or for dynamic usage for either residential or other usage. Orin Roberts - IP PROVISIONING Bell Canada From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Hadenfeldt, Andrew C Sent: May-29-17 11:56 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Oppose as written, +1 on the points below (leave /29 alone, and would prefer to see /56 rather than /60) -Andy From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Tuesday, May 23, 2017 2:02 PM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On Tue, May 23, 2017 at 2:35 PM, ARIN wrote: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Policy statement: Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to "more than a /28". Hello, In my opinion... Leave /29 alone or change it to "more than a single IP address." In these days of IPv4 shortage, substantial networks sit behind small blocks of public addresses. These networks should be documented with reachable POCs lest the anti-spam/virus/malware folks slam down /24 filters for lack of information about how misbehaving networks are partitioned. ? Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to "more than a /60". Change this to "more than a /56." Service providers should NOT be assigning /64's to end users. If you're doing that, you're doing it wrong. An IPv6 customer should be able to have more than one /64 subnet without resorting to NAT so /60 should be the absolute minimum end-user assignment, equivalent for all intents and purposes to an IPv4 /32. If we then want "equivalence" to the /29 policy so that individuals with the minimum and near-minimum assignment do not need to be SWIPed, it makes sense to move the next subnetting level up. In IPv6, assignment is strongly recommended on nibble boundaries, so that means /56. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com ?bill at herrin.us Dirtside Systems ......... Web: This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. From bill at herrin.us Tue May 30 09:41:24 2017 From: bill at herrin.us (William Herrin) Date: Tue, 30 May 2017 09:41:24 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin wrote: > Hello all, > > I am avidly following this discussion and based on my daily observances > (daily swips /subnets ), I would say Andy is closest to being practical. > > Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED > AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents > total chaos. > > With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests > a /56 OR LARGER NETWORK assignment be swiped. > > That would still leave /60 to /64 assignments as minimum assignment or for > dynamic usage for either residential or other usage. > Howdy, I don't like putting the SWIP requirement at /56 or larger because I think that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts I've read seem to have a pretty strong consensus that the minimum assignment to an end user should be either /48 or /56. Setting ARIN policy that encourages assignments smaller than -both- of these numbers would be a bad idea IMHO. Again I remind everyone that a /64 assignment to an end user, even for dynamic or residential use, is absolutely positively 100% wrong. Doing so prevents the end user from configuring their local lans as IPv6 is designed. They need at least a /60 for that. If you are assigning /64's to end users, you are doing it wrong. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Wed May 31 11:52:05 2017 From: jschiller at google.com (Jason Schiller) Date: Wed, 31 May 2017 11:52:05 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: WRT IPv6 can we solve this by requiring all fixed IPv6 customers (still allowing residential privacy) to SWIP, and allow dynamic customers up to (and including) /56 to only SWIP the parent block to the residential market? We would need someone to come up with a usable definition of fixed and dynamic... Any statically routed network is considered fixed. Any network announced by a customer to a provider via a routing protocol is considered fixed. Any network provided by a provider to a customer with the expectation that the address will not change is considered fixed (even if dynamic mechanisms are used to provide the address) [excluding re-terminations and divestitures] Any network with a customer specified ip6.arpa address is considered fixed. Only networks provided by a dynamic mechanism such as DHCPv6 with a sufficiently short lease such as 1 year or less and no customer expectation that the address will persist if the lease times out may be considered dynamic. On Tue, May 30, 2017 at 9:41 AM, William Herrin wrote: > On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin wrote: > >> Hello all, >> >> I am avidly following this discussion and based on my daily observances >> (daily swips /subnets ), I would say Andy is closest to being practical. >> >> Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED >> AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents >> total chaos. >> >> With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests >> a /56 OR LARGER NETWORK assignment be swiped. >> >> That would still leave /60 to /64 assignments as minimum assignment or >> for dynamic usage for either residential or other usage. >> > > Howdy, > > I don't like putting the SWIP requirement at /56 or larger because I think > that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts > I've read seem to have a pretty strong consensus that the minimum > assignment to an end user should be either /48 or /56. Setting ARIN policy > that encourages assignments smaller than -both- of these numbers would be a > bad idea IMHO. > > Again I remind everyone that a /64 assignment to an end user, even for > dynamic or residential use, is absolutely positively 100% wrong. Doing so > prevents the end user from configuring their local lans as IPv6 is > designed. They need at least a /60 for that. If you are assigning /64's to > end users, you are doing it wrong. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > > _______________________________________________ > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Wed May 31 13:23:34 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 31 May 2017 13:23:34 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: This idea kinda misses the entire point of what I seek to do with this proposal. The entire reason for my proposal is to make v6 equai or better than v4 when it comes to assignment registrations or SWIP. Since the smallest possible v6 network is /64, the current policy requires ALL v6 customers, regardless of static or dynamic assignments to be registered in SWIP. IPv4 customers of all types do not trigger a SWIP requirement, unless more than 7 v4 addresses are assigned. At nearly every ISP the vast majority of customers have only a single v4 address. This includes my home connection, and with this address I am able to run my own mailserver, webserver and gopher server. NONE of the proposals for v4 have ever suggested that I should have to register my single v4 address in SWIP. Of course this type of talk I see as a wish that the standard for SWIP in v4 was a /32. I have heard the community regarding total equality between v4 and v6, with only one other commenter in favor, and have given up on trying to change the current v4 SWIP standard from /29 or more. Therefore, read my draft as ONLY the v6 change. As to my IPv6 proposal regarding SWIP, based on the comments received so far, except for one person who totally rejected my Draft because changing the IPv4 standard for SWIP to more than 16 addresses from the current 8 addresses, everyone else responding supports changing the current point from a /64, or SWIP for everyone, to some level that small customers do not have to be SWIP'ed. The only point of discussion with this draft is to what level should be the maximum point be that does not require a SWIP registration. Since a vote for a bigger block without registration, effectively is a vote to allow the smaller included blocks without registration, I can say that of those who have expressed a preference, all are in favor of a /64 not needing SWIP. when you add up the preferences from the announcement of this draft until now, /56 seems to be the point of the majority. Do remember, that current policy (2.14) says that each site should receive a /48. I am asking for /60 exempt from SWIP, so some subnetting can be done, but of course would be happy with /56 being the max without SWIP instead. In my opinion, I have no problem with all assignments below the recommended /48 not triggering a SWIP requirement. Also, note that I am not proposing any changes whatsover to the enforcement policies of ARIN, and this is a subject for another Draft. As far as the suggestion to only SWIP the parent block, that would not work at all with my current WISP. This network assigns a /26 to each network point-to-multipoint sector, and the wan address is merely an address on that network. ALL customers regardless of type are placed on the subnet of their assigned link, and everything is static. Unlike "normal" network means, they could actually assign exactly 7 IPv4's to a customer. I also question why 100% SWIP on v6, because 99.9% of ISP's are not coming back for a new assignment. While SWIP is useful for network security and contact needs, this is NOT the purpose it was established. It was established to document an ISP's address utilization rates for ARIN to be used when the ISP requests more space. Since very few have come back to ARIN for more v6 space, I think its purpose is not needed until such time as an ISP needs to get its ducks together to ask for more IPv6 space, which with the larger space of v6 will be never for most ISP's. I also do not think ARIN's policies should be supporting the business models of the Geolocation providers, of which one of the most annoying customers of same is the Copyright Trolls. Even the "Residential Privacy" people must publically declare a zipcode, a goldmine for the Geolocation providers. I have recommended customers reducing log retention to 2 weeks, enough to cover true network security problems, but making response to the Copyright Trolls very easy, since with such a policy, a truthful answer of "Sorry, no information" reduces the staff time for these requests to close to zero. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 31 May 2017, Jason Schiller wrote: > WRT IPv6 can we solve this by requiring all fixed IPv6 customers > (still allowing residential privacy) to SWIP, and allow dynamic > customers up to (and including) /56 to only SWIP the parent > block to the residential market? > > We would need someone to come up with a usable definition > of fixed and dynamic... > > Any statically routed network is considered fixed. > > Any network announced by a customer to a provider > via a routing protocol is considered fixed. > > Any network provided by a provider to a customer > with the expectation that the address will not change > is considered fixed (even if dynamic mechanisms are > used to provide the address) > [excluding re-terminations and divestitures] > > Any network with a customer specified ip6.arpa address > is considered fixed. > > Only networks provided by a dynamic mechanism such as > DHCPv6 with a sufficiently short lease such as 1 year or less > and no customer expectation that the address will persist if > the lease times out may be considered dynamic. > > On Tue, May 30, 2017 at 9:41 AM, William Herrin wrote: > >> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin wrote: >> >>> Hello all, >>> >>> I am avidly following this discussion and based on my daily observances >>> (daily swips /subnets ), I would say Andy is closest to being practical. >>> >>> Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED >>> AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents >>> total chaos. >>> >>> With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests >>> a /56 OR LARGER NETWORK assignment be swiped. >>> >>> That would still leave /60 to /64 assignments as minimum assignment or >>> for dynamic usage for either residential or other usage. >>> >> >> Howdy, >> >> I don't like putting the SWIP requirement at /56 or larger because I think >> that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts >> I've read seem to have a pretty strong consensus that the minimum >> assignment to an end user should be either /48 or /56. Setting ARIN policy >> that encourages assignments smaller than -both- of these numbers would be a >> bad idea IMHO. >> >> Again I remind everyone that a /64 assignment to an end user, even for >> dynamic or residential use, is absolutely positively 100% wrong. Doing so >> prevents the end user from configuring their local lans as IPv6 is >> designed. They need at least a /60 for that. If you are assigning /64's to >> end users, you are doing it wrong. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ herrin at dirtside.com bill at herrin.us >> Dirtside Systems ......... Web: >> >> _______________________________________________ >> 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. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > From sethm at rollernet.us Wed May 31 22:11:46 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 31 May 2017 19:11:46 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: <93911c83-090c-3c9b-f4cb-163ce0289f1e@rollernet.us> On 5/31/17 10:23 AM, hostmaster at uneedus.com wrote: > > As to my IPv6 proposal regarding SWIP, based on the comments received so > far, except for one person who totally rejected my Draft because > changing the IPv4 standard for SWIP to more than 16 addresses from the > current 8 addresses, everyone else responding supports changing the > current point from a /64, or SWIP for everyone, to some level that small > customers do not have to be SWIP'ed. Remove all references to a policy change for IPv4 and I'm fine with whatever IPv6 threshold ends up being. I think the current IPv6 threshold is fine. I also don't really care what the IPv6 threshold is, so I'll leave the in depth discussion to everyone who does care. I'll follow whatever the NRPM ends up saying the threshold is for IPv6. But I oppose any changes to the IPv4 SWIP threshold. ~Seth From hannigan at gmail.com Wed May 31 22:57:42 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 01 Jun 2017 02:57:42 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <93911c83-090c-3c9b-f4cb-163ce0289f1e@rollernet.us> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <93911c83-090c-3c9b-f4cb-163ce0289f1e@rollernet.us> Message-ID: Someone want to remind us all of what the "benefits" of SWIP are? Best, -M< On Wed, May 31, 2017 at 22:12 Seth Mattinen wrote: > On 5/31/17 10:23 AM, hostmaster at uneedus.com wrote: > > > > As to my IPv6 proposal regarding SWIP, based on the comments received so > > far, except for one person who totally rejected my Draft because > > changing the IPv4 standard for SWIP to more than 16 addresses from the > > current 8 addresses, everyone else responding supports changing the > > current point from a /64, or SWIP for everyone, to some level that small > > customers do not have to be SWIP'ed. > > Remove all references to a policy change for IPv4 and I'm fine with > whatever IPv6 threshold ends up being. I think the current IPv6 > threshold is fine. I also don't really care what the IPv6 threshold is, > so I'll leave the in depth discussion to everyone who does care. I'll > follow whatever the NRPM ends up saying the threshold is for IPv6. > > But I oppose any changes to the IPv4 SWIP threshold. > > ~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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at datacate.com Wed May 10 17:02:39 2017 From: chris at datacate.com (Chris James) Date: Wed, 10 May 2017 21:02:39 -0000 Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> <92132621-af7c-b74b-828d-f606032a7948@egh.com> <7DCFE545-E93D-4804-88C5-7FCFB45704AB@arin.net> Message-ID: Unless reasonable efforts are made to contact the POC, and this includes researching and contacting the organization along with every possibly department, identifying clearly the reason for the call, and actually trying to update the POC, I fully entirely 100% disagree with discontinuing rDNS services. Image the negative affect to a small ISP who purchases a unit of a major corporation, somehow the transfer is not done properly, something is not updated properly, and suddenly every customer of that small ISP who does not realize they missed updating the POC on a /18 and now a few hundred small businesses are screwed? Image the reverse situation. A major corporation buys a small ISP, I know we care less and less about the negative impact of policy on ma bell, but how many innocent users will not receive email, how many inexperienced users cannot access their own regional bank due to SSL issues thanks to an arbitrary removal of a few pointers that cost absolutely nothing to keep up? I wholly disagree with policy that has the potential to negatively impact innocent or otherwise inexperienced users based on the unwillingness of an actual human person to do minor due diligence. If this is too costly an endeavor for ARIN, scrap the policy altogether. Am I reading too far into this or is this outcome entirely impossible? *Chris James* [image: Datacate] t. 916-526-0737 ext 1002 e. chris at datacate.com a. 2999 Gold Canal Dr., Rancho Cordova, CA 95670 w. https://www.datacate.net *__________________________________________* On Wed, May 10, 2017 at 12:28 PM, wrote: > So in effect, all the proposed 3.6.4 does is to formalize what is the > current practice of allowing the change. Thus, there should be no problems > with the change. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Wed, 10 May 2017, John Curran wrote: > > On 10 May 2017, at 2:34 PM, John Santos > >> wrote: >> ... >> I'm a little confused by this because my company is a legacy holder and >> I'm certain I've updated our POC information several times in the past. >> (At least once because the phone company changed our area code, once >> because the Post Office changed our ZIP code, and one of our original POCs >> retired and I changed our company's administrative POC as a result.) I've >> also changed our rDNS server addresses several times over the years. If it >> makes any difference, I have been responding to the annual "please validate >> your POC information" email from ARIN. >> >> Am I currently prohibited from making changes, or has maintaining the POC >> information been sufficient to retain my right to update our records? >> >> John - >> >> It?s a perfectly reasonable question (as there is quite a bit of >> misinformation out there?) >> >> At ARIN?s formation, the Board of Trustees decided that ARIN would >> provide registration >> services for these legacy number resources without requiring legacy >> resource holders >> to enter into a registration services agreement or pay any fees. >> >> All legacy number resource holders are provided these traditional >> registry services >> (including the ability to update their information in the ARIN registry) >> but also have >> the option to enter into an agreement and pay standard fees if they wish >> additional >> services or to formalize their contractual relationship with ARIN. >> >> Please refer to >> for details. >> >> Thanks! >> /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. > -- This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. This company is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at datacate.com Wed May 10 20:48:54 2017 From: chris at datacate.com (Chris James) Date: Thu, 11 May 2017 00:48:54 -0000 Subject: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation In-Reply-To: <709EF30F-FA42-4ABE-836B-BFAB0FF9546F@arin.net> References: <009501d2c435$a4cd6280$ee682780$@iptrading.com> <02fe01d2c820$1ed6ada0$5c8408e0$@iptrading.com> <999D8332-32EA-4990-890A-EFC5CBD25A63@panix.com> <92132621-af7c-b74b-828d-f606032a7948@egh.com> <7DCFE545-E93D-4804-88C5-7FCFB45704AB@arin.net> <709EF30F-FA42-4ABE-836B-BFAB0FF9546F@arin.net> Message-ID: Voluntary return of resource, and court order should be the only conditions in which a POC and rDNS pointer is removed. Possibly an exception for verified hijacking of resources, but even then the conditions would need to be ultra stringent and only to prevent further verified malicious activity. Removing a resource due to lack of updated information which could wholly be due to simple oversight, lack of former administrator documentation or even a spam filter will have negative repercussions for the internet as a whole with emphasis on smaller ISPs who can afford this the least. *Chris James* [image: Datacate] t. 916-526-0737 ext 1002 e. chris at datacate.com a. 2999 Gold Canal Dr., Rancho Cordova, CA 95670 w. https://www.datacate.net *__________________________________________* On Wed, May 10, 2017 at 5:17 PM, John Curran wrote: > On 10 May 2017, at 5:57 PM, hostmaster at uneedus.com wrote: > > > > Just as a point of information, can someone from ARIN tell us under what > conditions (if any) is the POC or the rDNS pointers removed under the > current policy? > > When the resources are reclaimed/returned/returned to ARIN, the number > resources > are updated in the registry to point to ARIN, including POC and reverse > DNS pointers. > Once reissued, they are changed once again (as it done with any issuance) > to point > to the new resource holder. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > > -- This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. This company is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. -------------- next part -------------- An HTML attachment was scrubbed... URL: