Re: [arin-ppml] Advisory Council Meeting Results - December 2015

- December 2015   Following the excellent example that Scott Leibrand has done over the years, I wish to convey my objections over the abandonment of 2015-8, which would allow End-users to SWIP.   Year after year, and issue after issue, John Curran tells us "this is the way we are d

Re: [arin-ppml] Thoughts on 2015-7

izations that have no > resources. > > I (and MJ) tried a more complicated version of this as ARIN-2014-20. > > Scott, do you want to consider my (friendly) amendment and draft some > text? > Do you want to consider what to do for organizations with no resources? > > > ___J

Re: [arin-ppml] 2-byte ASN policy

On Wed, Apr 6, 2016 at 4:24 PM, John Curran wrote: > On Apr 6, 2016, at 4:17 PM, Bill Buhler wrote: > > > > Thanks for the clarification John, > > > > So I understand you, regarding IPv4 you are recycling the deadbeat > resources already. > > > > My impression though is that you aren’t doing the

Re: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy

> On Apr 6, 2016, at 8:11 PM, Gary Buhrmaster wrote: > >> On Tue, Mar 22, 2016 at 4:55 PM, ARIN wrote: >> >> Policy statement: >> >> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the >> transfer:" >> >> Address resources from a reserved pool (including those desig

Re: [arin-ppml] ARIN 2-Byte ASN inventory and issuance (was: Re: 2-byte ASN policy)

Thanks, John. It sounds to me like ARIN is already doing the right thing (saving 2-byte ASNs for people who specifically want them), and that is sufficient for the time being. It does not appear that additional restrictions on who may request a 2-byte ASN are necessary at this time. If at some p

Re: [arin-ppml] ARIN 2-Byte ASN inventory and issuance

On Mon, Apr 11, 2016 at 12:24 PM, John Curran wrote: > > > On Apr 11, 2016, at 3:18 PM, Owen DeLong wrote: > > > > Pesonally, I believe we have a terminology problem more than anything > else. > > > > At this time, we should no longer be even considering “2-byte” ASNs. > > > > There are two clas

Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

+1 - I support as written.  -Scott _ From: Elvis Daniel Velea Sent: Friday, May 6, 2016 4:25 AM Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy To: I support the policy

Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

Well put, David. +1 -Scott _ From: David R Huberman Sent: Saturday, May 14, 2016 5:08 PM Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy To: Jason, 1) The policy in las

Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

Robert, Do you support or oppose ARIN-2015-3? -Scott _ From: Robert Jacobs Sent: Monday, May 16, 2016 10:32 AM Subject: Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy To: Owen DeLo

Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

> On May 16, 2016, at 10:36 AM, McTim wrote: > > On Sun, May 15, 2016 at 10:32 PM, Owen DeLong wrote: > > > > >> >> If we eliminate needs assessment, what mechanism assures that the transferee >> is actually a network operator? > > This, to my mind is the central question. Do we, as a co

Re: [arin-ppml] Draft Policy ARIN-2016-2 Change timeframes for IPv4 requests to 24 months

My understanding is that those on the waiting list would stay on the waiting list, approved for the blocks they're already approved for. We would not "grow" their approvals, as that would be unfair to those right behind them on the list, or let them get on the list a second time. Anyone who wants

Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns wrote: > Hi Andrew, > > I have a couple of questions about the policy proposal. > > On Section 8.5.2 Operational Use. > > First, why is this section even in there, does it serve some particular > purpose? > It prevents financial speculators, who have

Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

5.2 is the policy text that supports requiring the recipient to attest that they are using the addresses on an operational network. If that part is unclear, we would welcome suggestions for improving the text. There is a further attestation in 8.5.5 as well for organizations requesting more

Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

Mike, I think you're misunderstanding the intent here. This very simple "operational use" clause, that doesn't interfere with *any* legitimate transfers, is all that should be needed to prevent financial speculation, and allow us to dramatically simplify the needs test, or even remove it entirel

Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

aft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy To: Scott Leibrand , Michael Peddemors , John Curran Cc: Hi Scott,   I see the harm in the inclusion of non-operational text which seems to put into the NRPM something like a specific community expression against

Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

Matthew, Have converted your network to IPv6-only, turned off IPv4, and returned your IPv4 addresses to ARIN? If not, I think you know why IPv4 is still necessary, and why new and growing networks still need to acquire IPv4 addresses. And as long as organizations still need to get IPv4 addresses

Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

I've tried (to make editorial changes that don't change policy, just simplify it), and couldn't find any that usefully simplified policy with absolutely zero changes. If you are instead suggesting a wholesale duplication of sections 4 and 5 into section 8, as a precursor to simplifying the dupli

Re: [arin-ppml] re-org question

Bill, The intent of this policy text was that an organization receiving a sparsely used /16 would transfer the unused bits to other organization(s) that could use them. In your case, if you transferred all the /24s that are currently unused (without any renumbering), would the blocks you're keepi

Re: [arin-ppml] re-org question

Fair enough. If the 2010-6 language were removed, would that change your approach? Or is signing the RSA the main stumbling block for you? -Scott On Wed, Nov 9, 2016 at 12:36 PM, William Herrin wrote: > On Mon, Nov 7, 2016 at 2:07 PM, Scott Leibrand wrote: > > The intent of this po

Re: [arin-ppml] re-org question

safely removed, particularly in light of the RSA constraints that prevent ARIN from reclaiming resources due to lack of utilization. -Scott On Wed, Nov 9, 2016 at 2:10 PM, William Herrin wrote: > On Wed, Nov 9, 2016 at 3:41 PM, Scott Leibrand wrote: > > If the 2010-6 language were removed

Re: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement

Thanks, Alyssa, for saying what we were all thinking. In addition to the question of whether it's a good idea to contact a random subset of indirect POCs, there's also the question of whether it's even legal. If not, then that isn't a viable approach either. Personally, if we think indirect P

Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility

I would agree with this, and would support a policy proposal to remove the "reciprocal" requirement in ARIN inter-RIR transfer policy, leaving the "compatible, needs-based" requirement. It looks like this would simply be a one-word change, removing "reciprocal," from the first sentence of 8.4. -S

Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility

CC 35 > > APNIC 45 > > > > I would prefer a sentence, that allows for the relaxing of the reciprocal > rule, in the event the gaining RIR is below the global average in IPv4 > space. > > > > Kevin Blumberg > > > > *From:* ARIN-PPML [mailto:arin-ppml-bo

Re: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

Support. This proposal would make it easier to get currently-unused and/or inaccurately-registered addresses into productive use on the Internet, and/or update their registration to match the entity that is actually and legitimately using them. -Scott On Tue, Jan 24, 2017 at 1:34 PM, David Huber

Re: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

Wouldn't the existing language ("The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.") be good enough for those scenarios? The additional OR clause seems mostly meant to deal with defu

Re: [arin-ppml] 2016-3 Revisited

I support this proposal, either as amended thus far by David and the AC, or (preferentially) as suggested by Jason. I believe Jason's suggestion (restoring the "at least 50% utilization of each allocation and assignment" condition to the 8.5.7 conditions) would adequately address the "transfer /16

Re: [arin-ppml] 2016-3 Revisited

On Fri, Feb 3, 2017 at 8:46 AM, Jason Schiller wrote: > David, > > TL;DR > The policy says "one or more transfers up to the total size of their > current ARIN IPv4 address holdings" > > My read suggests you can do one or many transfers within a two year window > up to the amount approved. There

Re: [arin-ppml] 2016-3 Revisited

That would be a significant improvement on the current ("An organization may only qualify under 8.5.7 once every 6 months.") text. I would be equally fine with this text ("No more than a total of a /16 equivalent may be transferred under these provisions within any 6 month period." or similar) or

Re: [arin-ppml] 2016-3 Revisited - anti-abuse clause

>> ambivalent to one or more options, or support one or more options (with >>>> some preference). >>>> >>>> >>>> 1. demonstrate 80% utilization on average for all your IP space >>>> 2. get pre-authorization for 1 or more transfers u

Re: [arin-ppml] 2016-3 Revisited - anti-abuse clause

; > > *From:* ARIN-PPML [mailto:arin-ppml-boun...@arin.net] *On Behalf Of *Jason > Schiller > *Sent:* Tuesday, February 7, 2017 2:54 PM > *To:* Scott Leibrand > *Cc:* ARIN-PPML List > *Subject:* Re: [arin-ppml] 2016-3 Revisited - anti-abuse clause > > > > We ha

Re: [arin-ppml] Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers

I support this policy: I think that text being removed has reached the end of its useful life, and keeping it in place will do more harm than good in the future. Scott > On Mar 21, 2017, at 10:31 AM, ARIN wrote: > > On 16 March 2017, the ARIN Advisory Council (AC) advanced the following Draf

Re: [arin-ppml] Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers

It seems that this could be read as more restrictive than current policy. To make sure it isn't, we could do something like add the word "Alternatively," before "organizations may demonstrate a 24 month future projection" at the beginning of the newly added text. Scott > On Mar 21, 2017, at 1

Re: [arin-ppml] Draft Policy ARIN-2017-2: Removal of Community Networks

I support this policy until/unless we hear from an actual community network that is actually applying for space under the Community Networks section of the NRPM (and would not qualify as easily otherwise). Scott > On Mar 21, 2017, at 10:35 AM, ARIN wrote: > > On 16 March 2017, the ARIN Advis

Re: [arin-ppml] Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

I support this draft policy in principle, and am OK with it as written, as I think it accomplishes the laudable goal of allowing IPv4 transfers to more organizations who need them. I do have one quibble, which is that the "only when" language seems to be premised on the idea that each region shoul

Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-3: Alternative Simplified Criteria for Justifying Small IPv4 Transfers

Support. -Scott On Mon, Apr 10, 2017 at 1:41 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 05 April 2017 and decided to > send the following Recommended Draft Policy to Last Call: > > Recommended Draft Policy ARIN-2016-3: Alternative Simplified Criteria for > Justifying Small IPv4 Tra

Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers

Support. -Scott On Mon, Apr 10, 2017 at 1:45 PM, ARIN wrote: > The ARIN Advisory Council (AC) met on 05 April 2017 and decided to > send the following Recommended Draft Policy to Last Call: > > Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition > Transfers > > The AC provided

Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-3: Alternative Simplified Criteria for Justifying Small IPv4 Transfers

+1 to that being a useful editorial change consistent with the policy intent as I understand it. Scott > On Apr 18, 2017, at 6:54 PM, Martin Hannigan wrote: > > > > Makes sense to me and I'm the penultimate editorial change hater. > > Best, > > -M< > > >> On Tue, Apr 18, 2017 at 21:30 O

Re: [arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation

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 crea

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

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

Re: [arin-ppml] IPv4 SWIP requirements (?)

On Fri, May 26, 2017 at 3:32 PM, Ronald F. Guilmette wrote: > > In message <8a3a301d-39b5-4f81-8e2c-90e23b819...@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 day

Re: [arin-ppml] IPv4 SWIP requirements (?)

On Fri, May 26, 2017 at 4:26 PM, Ronald F. Guilmette wrote: > > In message pg3ze04...@mail.gmail.com> > Scott Leibrand wrote: > > >> Am I missing something? > > > >No, this proposal isn't drafting a new rule, but rather relaxing an > >existing o

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

On Tue, Jun 6, 2017 at 12:04 PM, William Herrin wrote: > On Tue, Jun 6, 2017 at 2:30 PM, Leif Sawyer wrote: > >> The boundaries at /60, /56, and /48 have all been discussed. If one is >> more favorable than >> the other, and you would like to see the proposal edited to use that one, >> we will

Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

It looks like /60 still needs to be changed to /56 to reflect the consensus on PPML. Or was there some reason not to do that (yet)? Scott > On Jun 7, 2017, at 11:58 AM, ARIN wrote: > > The following has been revised: > > * Draft Policy ARIN-2017-5: Equalization of Assignment Registration > r

Re: [arin-ppml] Draft Policy ARIN-2017-6: Improve Reciprocity Requirement for Inter-RIR Transfers

I strongly oppose this draft policy. Preventing transfers because someone else prevents transfers is not helpful. Scott > On Jun 20, 2017, at 10:37 AM, ARIN wrote: > > On 15 June 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-241: > Improve Reciprocity Requirement for Inter-RIR Tra

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

On Sat, Jul 15, 2017 at 10:24 AM, William Herrin wrote: > On Sat, Jul 15, 2017 at 8:52 AM, John Curran wrote: > >> Such a separation doesn’t preclude the community from adopting policy >> which >> references the present or future state of routing (note, for example, the >> use of >> “multihoming

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

As I understand it, if the ISP assigned you a /48 and individually routed the /64s for you, they would only have to create a single SWIP entry for the /48, and the street address of your central location (or your administrative HQ, if different) would be perfectly appropriate for that SWIP. I agre

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

This looks good: I support. For clarity, so we don't all have to do it, and to help make sure we're not missing anything, here's what the resulting 6.5.5 looks like after modification: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

> On Jul 21, 2017, at 8:31 PM, John Springer <3jo...@gmail.com> wrote: > > I support this Draft Policy as re-written. > > I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, > but was not reassured when the discussion veered to consider prefixes between > /48 and /64. A

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

t; by deleting the phrase "holding /64 and larger blocks" > > BUT. These observations do not appear to have any effect one way or the other > on the policy text. To me, picking a different number does not have anything > to do with disparity, but so what? Changing the IPV6 S

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

If I, as an End User network, want to inform geolocation providers of where I'm using each netblock, having them assigned to me in the whois DB with an appropriate address is one of the best ways to do that. But if I'm running a geolocation service, I can't rely on whois as the sole source of data

Re: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity Requirements for Inter RIR Transfers

Agreed: this proposal is a very bad idea for many reasons, and I would encourage the AC to abandon it prior to the next public policy meeting. If you're reading this message on PPML, feel like this policy is generally a bad idea, but haven't commented on it yet: please do. The AC needs to hear cle

Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

+1 (support as written) On Wed, Sep 6, 2017 at 12:39 PM, Mike Burns wrote: > Ah! Thank you David! > > I though it meant available inventory. > > > > I am okay with the sentence in that case and I understand why it was > placed there. > > I support the policy as written. > > > > Regards, > > Mike

Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

IMO we're overthinking this. The problem is simply that not all companies can get access to the IP addresses they need to run their businesses. The fix is to enable transfers from ARIN to all other regions, and between as many regions as are willing to participate. Only LACNIC and AfriNIC don't

Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

+1 I support RDP ARIN-2017-5 as written. -Scott On Tue, Sep 26, 2017 at 10:31 AM, ARIN wrote: > On 21 September 2017, the ARIN Advisory Council (AC) advanced the > following Draft Policy to Recommended Draft Policy status: > > ARIN-2017-5: Improved IPv6 Registration Requirements > > The text o

Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

I support this policy proposal with "should" and would also support it with "shall". I don't think it's a big deal either way. -Scott On Thu, Sep 28, 2017 at 8:20 AM, Jason Schiller wrote: > John, > > Thanks. > > My intention was to make 6.5.5.4 not be any less required or give the > impressio

Re: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

+1 - Support as written. I know +1's aren't strictly needed in Last Call, but I want to explicitly state that I agree with the AC that sufficient consideration and discussion was given to the "should" vs. "shall" question before and during the PPM, and therefore I agree it is appropriate to send t

Re: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers

I believe this problem statement is incorrect, and therefore oppose the policy proposal as-is. 8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled up) to allow ISPs to transfer a /24 without justification. It was *not* intended to "match the previous policy" in

Re: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6)

+1 - support as written. On Tue, Nov 21, 2017 at 2:42 PM, ARIN wrote: > On 16 November 2017, the ARIN Advisory Council (AC) advanced > "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM > Section 4.2.1.6)" to Draft Policy status. > > Draft Policy ARIN-2017-10 is below and can

Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment

+1 - I support the general idea here, and would be fine with this text as-is. I suspect others will have feedback on the exact mechanisms prescribed here, so I'm expressing no prior opinion on any changes there. -Scott On Tue, Nov 21, 2017 at 2:43 PM, ARIN wrote: > On 16 November 2017, the ARI

Re: [arin-ppml] Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large, IPv4 Reassignments/Reallocations

+1 - Support Do we have any statistics on the last time 4.2.3.5 was invoked and/or frequently it was invoked? I suspect it's been awhile... -Scott On Tue, Nov 21, 2017 at 2:44 PM, ARIN wrote: > On 16 November 2017 the ARIN Advisory Council (AC) advanced > "ARIN-prop-248: Remove ARIN Review Re

Re: [arin-ppml] Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large, IPv4 Reassignments/Reallocations

rience.pdf > Transcript: https://www.arin.net/vault/participate/meetings/ > reports/ARIN_40/ppm1_transcript.html#anchor_5 > Video: https://www.youtube.com/watch?v=QVsfVMG_6fA > > FYI, this report is the genesis for what is now ARIN-2017-9 > and ARIN-2017-10 as well. > > Hope

Re: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers

the /24 as > initial no questions asked size or a /21? > > What do others prefer? > > .Andrew > >> On Nov 21, 2017, at 2:52 PM, Scott Leibrand wrote: >> >> I believe this problem statement is incorrect, and therefore oppose the >> policy proposal as-i

Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment

This would be a new policy proposal. If you'd like to discuss it before deciding whether to formally propose something, I would recommend a new thread, as it's off-topic for this thread. -Scott On Mon, Nov 27, 2017 at 12:35 PM, Andrew Bagrin wrote: > I’d also like to see a $100 monthly fee per

Re: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers

. I'd > think that could happen here on this list or at a meeting and thus no policy > change is needed. > > Andrew > >> On 12/4/2017 2:47 PM, David Huberman wrote: >> Andrew, >> >> It’s unclear to me that /21 is the correct boundary, especi

Re: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers

Quoting myself: > If there are organizations transferring blocks larger than a /24 for whom > officer-attested justification is burdensome (to them or to ARIN) I’d like to > understand what is burdensome, so we can figure out how to reduce that > burden. If not, then implementing section 8 as w

Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers

On Wed, Jan 31, 2018 at 12:07 PM, Job Snijders wrote: > On Wed, Jan 31, 2018 at 12:01:44PM -0800, Chris Woodfield wrote: > > The thread that precipitated this proposal is here: > > > > http://lists.arin.net/pipermail/arin-ppml/2017-December/032112.html > >

Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers

> On Feb 3, 2018, at 5:12 AM, hostmas...@uneedus.com wrote: > > I can only really think of three: > > 1) A company is relocating its headquarters from a location served by an RIR, > to another location served by a different RIR, and wants everything in their > new home region. > > 2) A compan

Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon Reassignment

How do we address the risk that companies with fully automated whois-population systems simply don't bother to do that research, and their delegation ends up not getting added to whois at all? This may be an implementation detail, but I think we should make sure the policy allows for an option for

Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon Reassignment

Oh, I forgot to mention, I support the proposal in principle and as written. Thanks, Scott On Tue, Mar 13, 2018 at 1:11 PM, Brian Jones wrote: > I support draft proposal 2017-12. It is a good step forward for POC > validation. > > -- > Brian > ​ E Jones > Agile Process Engineer > ​Virginia Tech

Re: [arin-ppml] ARIN-2018-1: Allow Inter-regional ASN Transfers

If you operate a network with peering sessions, and you are forced to renumber your ASN, you either need to convince all of your peers to set up new sessions (which can be a lot of work, and usually means at least some of them will refuse/fail to do so), or you need to local-as prepend the old ASN

Re: [arin-ppml] Draft Policy ARIN-2018-5: Disallow Third-party Organization Record Creation

I support the intent here, but wonder if this really requires us to add so many verbose new sections to the NRPM. Isn't this more of an operational practice we'd like ARIN to change? Could it go through as an ACSP suggestion and consultation instead of a policy change? -Scott On Tue, Nov 20, 20

Re: [arin-ppml] Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements

Thanks for clarifying that, Chris. I support this draft policy proposal: forcing applicants to wait to get into line for free space will at least slow down any attempts to make money off the free pool via the waiting list. Scott > On Mar 3, 2019, at 10:02 AM, Chris Woodfield wrote: > > Hi To

Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

I support Draft Policy ARIN-2019-2. IMO limiting waiting list recipients to a /22 is a reasonable approach that somewhat reduces the gains for fraudulent activity, and ensures that ARIN can serve more legitimate requests for each block it reclaims/receives. Organizations needing more than a /22

Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

I'll throw my vote behind "those on the waiting list get a new chance to set their minimum acceptable size, consistent with the new policy, and then keep their place in line." The applicant's originally approved request should continue to serve as a pre-approval for transfer of the larger block.

Re: [arin-ppml] prop266 - re-framing the discussion

Do we have any evidence that 1) a significant fraction of BGP hijacking (announcement in BGP of address space registered by an RIR to another organization that has not authorized them to use it) is being performed by organizations that have other address space directly registered to them by an

Re: [arin-ppml] prop266 - re-framing the discussion

> On May 2, 2019, at 8:29 AM, Fernando Frediani wrote: > >> On 02/05/2019 12:16, Scott Leibrand wrote: >> >> ARIN’s only authority is to over their registry of who “has” which >> addresses, so the only thing I can imagine they could do would be to &

Re: [arin-ppml] prop266 - re-framing the discussion

Do you have any reason to believe that ARIN getting involved in real-time notification of BGP hijacking, with or without firmly worded language and with or without an implied threat, will be any more effective than current methods of shutting down hijacks once they've started? My impression is tha

Re: [arin-ppml] prop266 - re-framing the discussion

On Thu, May 2, 2019 at 3:06 PM Carlos Friaças wrote: > > On Thu, 2 May 2019, Scott Leibrand wrote: > > > Do you have any reason to believe that ARIN getting involved in > real-time notification of BGP hijacking, with or without firmly worded > language and with or without an

Re: [arin-ppml] Fwd: Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet Requests

There are organizations of all sizes with direct unmet needs for address blocks of all sizes up to /16 or larger. The waitlist is *not* intended to meet all such requests: it simply can't be done, because the free pool is empty, and there is way more demand than supply at a price of ~$0. Rather,

Re: [arin-ppml] ARIN-PPML Digest, Vol 167, Issue 80

dy 'help' to >arin-ppml-requ...@arin.net > > You can reach the person managing the list at >arin-ppml-ow...@arin.net > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of A

Re: [arin-ppml] Fwd: Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet Requests

If we did this, I suspect what would happen for the foreseeable future is that all reclaimed space would be assigned out as /24s to everyone willing to accept a /24 to fulfil their request. Anyone who insisted on a larger block would get nothing, so there'd be no incentive to do so. That would have

Re: [arin-ppml] Of interest?

> On May 14, 2019, at 5:01 PM, William Herrin wrote: > > On Tue, May 14, 2019 at 3:58 PM John Curran wrote: > > You ask: "Was that ever in doubt?" Not by me, but from time to time we’ve > > had folks raise questions about the legal enforceability of the RSA. > > > > The precedent set is tha

Re: [arin-ppml] Of interest?

How would ARIN know whose pictures they were? If they were presented with forged copies of identity documents for non-existent people, how do you expect they would validate whether they're legitimate or not? Particularly if the scammer had captured a notary willing to falsely attest to the validi

Re: [arin-ppml] Solving the squatting problem

Why do you need an RIR to allocate anything if you just want to use 240/4 as private space? Wouldn’t it be sufficient to patch your kernels on your servers and network gear etc.? That’s not a trivial amount of work, but it would be easier than convincing 5 registries or a standards body to go al

Re: [arin-ppml] Solving the squatting problem

it’s not like anyone else is going to be using those numbers for anything that might conflict. >> Scott Leibrand wrote : >> That said, it’s not that difficult to use IPv6 inside your own network to >> replace RFC1918 space > > You have no bloody idea about what my own net

Re: [arin-ppml] Revised - Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet Requests

I support the AC’s recommendations, and consider them sufficient to resume waitlist allocations. I would also be fine with Michael’s #2 (non-transferability of waitlist space), but would consider that a new proposal. I don’t support a larger (/21) limit. Scott > On May 24, 2019, at 10:18 AM,

Re: [arin-ppml] Revised - Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet Requests

chael > > Sent from my iPhone > >> On 25 May 2019, at 03:27, Scott Leibrand wrote: >> >> I support the AC’s recommendations, and consider them sufficient to resume >> waitlist allocations. >> >> I would also be fine with Michael’s #2 (non-transf

Re: [arin-ppml] ARIN-PPML Digest, Vol 167, Issue 153

What rationale is there for a /21 limit vs. /22, other than “I need more than one /22, and think my needs for a second /22 are more important than others’ needs for a first”? Scott > On May 24, 2019, at 11:42 AM, Christian Lefrançois > wrote: > > I disagree with /22 limit, should be /21, the

[arin-ppml] IP leasing policy (was: Waiting List IPv4 blocks transferred after issuance)

(New subject line for a new topic.) You just described a lease policy: one where leasing is not allowed. Such a policy would have to exist to be enforced. Right now there is no policy, so leasing is allowed because it's not prohibited. ISPs lease space to their customers all the time, bundled w

Re: [arin-ppml] IP leasing policy

On Wed, May 29, 2019 at 4:11 PM Fernando Frediani wrote: > On 29/05/2019 19:26, Scott Leibrand wrote: > > (New subject line for a new topic.) > > You just described a lease policy: one where leasing is not allowed. Such > a policy would have to exist to be enforced. Rig

Re: [arin-ppml] IP leasing policy

On May 29, 2019, at 5:13 PM, Mike Burns wrote: > > Hi Scott and Fernando, > > Thank you for the change of subject and the discussion. > For the present, we should have a policy that recognizes legitimate leasing > types (LOA, VPN) and requires the same sorts of assignment and delegation > rec

Re: [arin-ppml] IP leasing policy

get assurance that a lease policy would be within our scope as > policymakers from a person better positioned to make the call? > > Regards, > Mike > > > From: Scott Leibrand > Sent: Thursday, May 30, 2019 1:23 AM > To: Mike Burns > Cc: arin-ppml > Subject: R

Re: [arin-ppml] Looking for final show of support on revised Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet Requests

+1 support for the draft policy as written, and to Leif's other points. -Scott On Thu, Jun 6, 2019 at 10:26 AM Leif Sawyer wrote: > +1 support the policy change as currently written > > > > > > Also, as a general reminder, we don’t have to get this **perfect** out > of the gates, and we -the c

arin-ppml@arin.net

Yes, yes, yes, and yes. This sort of flexibility would be useful and helpful for multinationals that want to consolidate RIR accounts after acquisitions. It would probably also provide a way to bypass ARIN policy, so we should think carefully about whether all resources (such as waiting list s

Re: [arin-ppml] Draft Policy ARIN-2019-15: Hijacking Authorization Not-intended

I agree with David, that a simple one-word change here would be best, and we should clarify the problem statement to refer to the "perverse reading" as "implicit", not "explicit". I think the "actual" vs. "current" language is just a (fairly common) translation issue/misunderstanding: as I underst

Re: [arin-ppml] Draft Policy ARIN-2019-10: Inter-RIR M&A - Seeking Community Comments

On June 18 I commented that "It would probably also provide a way to bypass ARIN policy, so we should think carefully about whether all resources (such as waiting list space) should be transferable this way." Would it be better to limit the applicability of ARIN-2019-10 to only apply to space that

Re: [arin-ppml] Draft Policy 2019-8 Clarification of Section 4.10 for Multiple Discrete Networks

I am in favor of this change. We should be encouraging people to use NRPM 4.10 where applicable instead of sitting on the general waiting list. -Scott On Mon, Jul 15, 2019 at 11:44 AM Owen DeLong wrote: > Hello, everyone. > > The AC is currently considering this draft policy which would provide

Re: [arin-ppml] Draft Policy 2019-8 Clarification of Section 4.10 for Multiple Discrete Networks

If an organization runs multiple discrete networks, how do you propose that they NAT each site without IPv4? Discrete networks, by definition, do not have internal connectivity between them. Scott > On Jul 15, 2019, at 12:03 PM, hostmas...@uneedus.com wrote: > > I am opposed. > > This space

Re: [arin-ppml] Draft Policy ARIN-2019-12: M&A Legal Jurisdiction Exclusion

Allowing entities outside the ARIN region to continue holding addresses originally assigned to an ARIN-region organization to which the non-ARIN-region entity is a legal successor seems reasonable to me, and less fraught than allowing IPv6 and IPv4 waitlist space to be M&A transferred to another

Re: [arin-ppml] Revised/Retitled - Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts

Strongly opposed as written. This policy would require that all "abuse reports receive a response" from "a human processor who evaluates each message received", which constitutes an inappropriate interference in the business operations of ISPs, and presents a denial of service vector. There are m

  1   2   3   >