Re: [arin-ppml] Revised - ARIN-2023-8: Reduce 4.1.8 Maximum Allocation

[Scott Leibrand]

The point isn't to "improve the visual appearance of the waiting list
numbers". Everyone knows the free pool is empty except for the reclaimed
dregs, and we're deciding who should get how much of the dregs. The point
of this proposal, limiting the maximum allocation to /24, is to allocate
smaller netblocks to organizations that have been waiting a shorter amount
of time, instead of making everyone wait longer while those with a
non-time-sensitive justification for a larger block can get one and those
who only need a smaller block wait in line longer.

Another alternative to limiting everyone to a /24 would be to prioritize
the waitlist such that everyone's place in line is determined by how long
they've been waiting divided by how many /24s they're requesting. So at any
given time, we might be fulfilling /24 requests that have been waiting 6
months, /23 requests that have been waiting a year, and /22 requests that
have been waiting 2 years. (Or 1, 2, and 4 years, respectively.) That way
no one is penalized for accepting a smaller block, and an organization who
can usefully use a /24 now and a /24 later gets a /23 worth of space in the
same amount of time as someone holding out for a contiguous /23.

-Scott

On Fri, Feb 16, 2024 at 12:56 PM Denis Motova  wrote:

> Dear William,
>
> I appreciate your message and your input.
>
> I have some reservations about agreeing with the statement you made, and
> I'll explain my reasoning below:
>
> I strongly believe that there are numerous legitimate businesses currently
> on the waiting list seeking IP space allocations of /22, /23, and /24. By
> removing the option for these allocations, we essentially transform the
> waiting list into what you described in a previous post as catering to
> "hobbyists and speculators." It's unlikely that any serious company would
> require only 256 IPs within a network; that's essentially a micro-network.
>
> As you are aware, there are multiple avenues for obtaining IP space,
> including the waiting list and authorized purchase methods. From my
> perspective, if a business urgently needs IP space, they would likely
> follow the example of AWS and invest in acquiring the necessary resources
> rather than wait through the waiting list.
>
> For instance, one of our customers acquired a /17 by purchasing it from
> the market after providing justifications to ARIN for the IP space. While
> this involved a significant financial investment, it demonstrated the
> seriousness of their business needs.
>
> I fail to see the value in limiting everyone's network size solely to
> improve the visual appearance of the waiting list numbers.
>
> Thank you once again for your collaborative spirit and feedback.
>
> Sincerely,
> Denis
>
>
> On 16 Feb 2024, at 15:52, William Herrin  wrote:
>
> On Fri, Feb 16, 2024 at 8:52 AM Denis Motova  wrote:
>
> A. Decreasing the allocation to a /24 means that new allocation
> holders would receive a minuscule network, hardly sufficient for
> small to mid-sized deployments.
>
>
> Hi Denis,
>
> At this point, the wait list is for hobbyists and speculators: people
> who can afford to wait, which a serious business cannot.
>
> Tell me I'm wrong.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>
>
>
>
>
> Denis Motova
> 1684 Medina Road  #118
> Medina, OH  44256
>
> Cell:  +598 096 886 200
> Email: dmot...@brcrude.com
> Website: www.brcrude.com
> Time zone: GMT -3
>
>
> [image: image001.png]
>
>
> DISCLAIMER: This electronic transmission and/or attached document(s) have
> not been verified or authenticated and are not to be considered a
> solicitation for any purpose in any form or content, nor an offer to sell 
> and/or
> buy securities and or properties. Merely describing the details of an
> existing private transaction does not constitute an offer or solicitation
> of any kind and, if presented, is done so as a request for information.
> Upon receipt of these documents you, as the recipient(s), hereby acknowledge
> this warning and disclaimer.  It is important that you do your due diligence
> on any and all commodity offers as we do not warrant any offers that we 
> forward
> from any other source. We make all attempts to verify information and 
> documents
> as much as possible but we can't guarantee authenticity.
>
> This email and its attachments may contain information that is privileged
> or confidential or legally exempt from disclosure, dissemination,
> distribution or reproduction by anyone other than the intended recipients.
>  If you are not the intended recipient, please immediately notify us and 
> permanently
> delete the original and any copies thereof.
>
> This email is covered by the Electronic Communications Privacy Act of
> 1986, Codified at 18 U.S.C. §§ 1367, 2510-2521, 2701-2710, 3121-3126. See
> http://www.ftc.gov/privacy/glbact/glbsub1.htm Gramm-Leach-Bliley Act 15
> USC, Subchapter I, Sec. 6801-6809.   This email and the attached related
> 

Re: [arin-ppml] AC candidates

[Scott Leibrand]

There is a kernel of truth behind Bill’s provocative framing. Much PPML 
discussion historically started as wordsmithing, which spawned real debate in 
many cases. Now, that all happens in private, and we only get discussion on 
more contentious topics. That often means the discussion we do get is mostly 
religious, from the Usual Suspects. So in a very real sense, ARIN and the AC 
have severed one good pipeline for engaging and evaluating new AC members. 

But we also don’t have much important policy work remaining. So there isn’t 
much reason for lots of folks to remain highly engaged on PPML like they did 
when we were designing IPv6 and IPv4 transfer policy and then tweaking it to 
reflect real-world usage. Now most of the activity on this list is cleanup and 
almost-editorial changes. 

Scott

> On Oct 26, 2023, at 10:43 AM, William Herrin  wrote:
> 
> On Thu, Oct 26, 2023 at 10:18 AM Owen DeLong  wrote:
>> I know taking pot shots at the PDP and the AC is one of your favorite
>> hobbies, but I think you’re a bit off base on this one.
> 
> Stick your fingers in your ears if you like. I've watched PPML
> participation die the death of a thousand cuts and it's no mystery to
> me what inflicted the wounds.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2022-12: Direct Assignment Language Update

[Scott Leibrand]

The placement of "only" in "All ISP organizations with only IPv4 addresses
from an upstream provider qualify for an initial allocation of up to a
/22..." would have a presumably unintended effect of excluding ISP
organizations that have both IPv4 and IPv6 addresses from an upstream
provider. I think you want it to say something like "All ISP organizations
with IPv4 addresses solely from upstream provider(s) qualify..."

-Scott

On Wed, Aug 2, 2023 at 3:06 PM ARIN  wrote:

> The following Draft Policy has been revised:
>
>
>
> * ARIN-2022-12: Direct Assignment Language Update
>
>
>
> Revised text is below and can be found at:
>
>
>
> https://www.arin.net/participate/policy/drafts/2022_12/
>
>
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion 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/participate/policy/pdp/
>
>
>
> Draft Policies and Proposals under discussion can be found at:
>
>
>
> https://www.arin.net/participate/policy/drafts/
>
>
>
>
>
> Regards,
>
>
>
> Eddie Diego
>
> Policy Analyst
>
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
>
> Draft Policy ARIN-2022-12: Direct Assignment Language Update
>
>
>
> Problem Statement:
>
>
>
> As a result of ARIN's fee harmonization direct assignments are no longer
> being utilized within ARIN databases therefore language around that has
> been deprecated and should be modernized.
>
>
>
>
>
> Policy Statement:
>
>
>
> Section 3.6.3:​
>
>
>
> Change paragraph 1 text​
>
>
>
> FROM: “This policy applies to every Organization that has a direct
> assignment, direct allocation, or AS number from ARIN”​
>
>
>
> TO: “This policy applies to every Organization that has Internet number
> resources registered with ARIN"​
>
>
>
> RESULT: “This policy applies to every Organization that has Internet
> number resources registered with ARIN (or one of its predecessor
> registries) or a reallocation from an upstream ISP. This includes but is
> not limited to upstream ISPs and their downstream ISP customers (as defined
> by NRPM 2.5 and 2.6), but not reassignments made to their downstream end
> user customers.”
>
>
>
>
>
> Section 4.2.2:​
>
>
>
> Reorganize and adjust text as follows
>
>
>
> FROM:​
>
>
>
> 4.2.2. Initial Allocation to ISPs​
>
>
>
> All ISP organizations without direct assignments or allocations from ARIN
> qualify for an initial allocation of up to a /22, subject to ARIN’s minimum
> allocation size.​
>
>
>
> All ISP organizations without direct allocations, direct assignments,
> re-allocations or reassignments automatically qualify for a /24. These
> organizations are exempt from requirements of showing the efficient
> utilization of previously held IPv4 space. These organizations may qualify
> for a larger than a /24 by documenting how the requested allocation will be
> utilized within the request size specified in 4.2.4.3.​
>
>
>
> ISPs holding re-allocations and/or reassignments must show the efficient
> utilization of their resources consistent with the requirements in sections
> 4.2.3 and 4.2.4.​
>
>
>
> TO:​
>
>
>
> 4.2.2. Initial Allocation to ISPs​
>
>
>
> 4.2.2.1 ISPs without existing IPv4 addresses​
>
>
>
> All ISPs without any IPv4 addresses automatically qualify for a /24. These
> organizations are exempt from requirements of showing the efficient
> utilization of previously held IPv4 space. These organizations may qualify
> for a larger than a /24 by documenting how the requested allocation will be
> utilized within the request size specified in 4.2.4.3.
>
>
>
> 4.2.2.2 ISPs with existing IPv4 addresses​
>
>
>
> All ISP organizations with only IPv4 addresses from an upstream provider
> qualify for an initial allocation of up to a /22, subject to ARIN’s minimum
> assignment size.​
>
>
>
> 4.2.2.3 Qualifying for increased initial assignments​
>
>
>
> All ISP organizations are exempt from requirements of showing the
> efficient utilization of previously held IPv4 addresses. These
> organizations may qualify for a larger than a /24 by documenting how the
> requested allocation will be utilized within the request size specified in
> 4.2.4.3.​
>
>
>
> ISPs holding re-allocations and/or reassignments must show the efficient
> utilization of their resources consistent with the requirements in sections
> 4.2.3 and 4.2.4.​
>
>
>
>
>
> Section 4.3.2:​
>
>
>
> Change paragraph 1 text​
>
>
>
> FROM: "End-user organizations without direct assignments or allocations
> from ARIN"​
>
>
>
> TO: “End-user organizations without IPv4 resources directly registered
> with ARIN”​
>
>
>
> RESULT: “End-user organizations without IPv4 directly registered with ARIN
> qualify for an 

Re: [arin-ppml] Re-thinking Section 8.5.6

[Scott Leibrand]

No. 

If a business can’t afford to may market price for addresses, they don’t have 
as much need for them as someone who can, and shouldn’t expand that part of 
their business. If an organization has addresses that they have a stronger 
economic incentive to hold than to free up and sell/lease, then we shouldn’t be 
trying to find policy levers to force them to do something (economically) 
inefficient. 

Scott

> On Jul 20, 2023, at 1:45 PM, A N  wrote:
> 
> 
> On behalf of the ARIN AC Policy Experience Working Group, and in response to 
> the Policy Implementation and Experience Report presented at ARIN 51, we're 
> looking for input on a possible proposed revamp of NRPM Section 8.5.6 
> "Efficient Utilization of Previous Blocks". 
> 
> The crux of the issue is there are very large orgs that could have a /8 or 
> more of unused space, yet still qualify for more based on the current policy 
> ("must have efficiently utilized at least 50%"). Smaller orgs with more 
> immediate needs are in competition for the space, and prices are driven up. 
> 
> The Working Group would like some input on this before drafting a proposal. 
> Input or thoughts are welcome about: 
> - should the utilization be raised, and if so, to what threshold? 
> - should utilization criteria be tied to the size of the org, in other words 
> tiered?
> - any other thoughts.
> 
> Thanks much! 
> Anita
> 
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs

[Scott Leibrand]

As an IXP participant, +1 to continuing to allocate IXPs /24s upon request 
whenever doing so will mean IXP participants don’t have to subsequently 
renumber. But for IXPs with no credible plans to need a /24, no objections to 
allocating a smaller block by default. 

Scott

> On Jun 20, 2023, at 3:05 PM, William Herrin  wrote:
> 
> On Tue, Jun 20, 2023 at 8:54 AM ARIN  wrote:
>> ARIN will make IPv4 micro-allocations to critical infrastructure providers 
>> of the Internet, including public internet exchange points (IXPs), core DNS 
>> service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well 
>> as the RIRs and IANA. These allocations will be no smaller than a /26 for 
>> IXPs, or a /24 for other allocations that require global reachability of the 
>> assigned allocation. Multiple allocations may be granted in certain 
>> situations.
> 
> I generally agree with this, although I'd make the minimum /27.
> There's no need to assign a /24 to something that neither requires
> that many IP addresses nor requires global routability, and there are
> private interconnects with a small number of participants that would
> benefit from addresses guaranteed to be unique. However...
> 
> 
>> An IXP requesting an allocation larger than a /26 must show an immediate 
>> need to utilize more than 25% of the requested allocation size upon initial 
>> commissioning.
> 
> I vehemently disagree with this. Expecting to -eventually- have more
> than 126 participants should be more than adequate to justify a /24
> for an IXP. IPv4 addresses are not so unobtainable that we need to
> force IXPs into a regime where they have  a messy addressing problem,
> possible renumbering and flag days on the exchange.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2023-3: Amendment of the waitlist agreement to include a restriction on leasing

[Scott Leibrand]

Is leasing defined anywhere in the NRPM? How would this be enforced? Is the 
intent to disallow all reassignments? To get ARIN into the business of 
inspecting customer contracts and network configs to see if there is a bona 
fide connectivity relationship vs. a fig-leaf one? Something else?

Scott

> On Jun 20, 2023, at 8:54 AM, ARIN  wrote:
> 
> 
> On 15 June 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-321: 
> Amendment of the waitlist agreement to include a restriction on leasing” as a 
> Draft Policy.
>  
> Draft Policy ARIN-2023-3 is below and can be found at:
>  
> https://www.arin.net/participate/policy/drafts/2023_3
>  
> You are encouraged to discuss all Draft Policies on PPML. The AC will 
> evaluate the discussion 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/participate/policy/pdp/
>  
> Draft Policies and Proposals under discussion can be found at: 
> https://www.arin.net/participate/policy/drafts/
>  
> Regards,
>  
> Eddie Diego
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>  
>  
> Draft Policy ARIN-2023-3: Amendment of the waitlist agreement to include a 
> restriction on leasing
>  
> Problem Statement:
>  
> Currently section 4.18 prohibits the transfer of waitlist space for a period 
> of 60 months.  However, there are no restrictions on leasing out the space 
> immediately after obtaining it from the waitlist.
>  
> Policy statement:
>  
> Modify the current text in 4.18 from:
>  
> ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 
> 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an 
> organization may qualify for at any one time is a /22. Organizations will be 
> able to elect a smaller block size than they qualify for down to a /24. 
> Organizations which hold more than a /20 equivalent of IPv4 space in 
> aggregate (exclusive of special use space received under section 4.4 or 4.10) 
> are not eligible to apply. Address space distributed from the waitlist will 
> not be eligible for transfer, with the exception of Section 8.2 transfers, 
> for a period of 60 months. This policy will be applied to all future 
> distributions from the waitlist to include those currently listed.
>  
> to
>  
> ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 
> 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an 
> organization may qualify for at any one time is a /22. Organizations will be 
> able to elect a smaller block size than they qualify for down to a /24. 
> Organizations which hold more than a /20 equivalent of IPv4 space in 
> aggregate (exclusive of special use space received under section 4.4 or 4.10) 
> are not eligible to apply. Address space distributed from the waitlist will 
> not be eligible for lease or transfer, with the exception of Section 8.2 
> transfers, for a period of 60 months. This policy will be applied to all 
> future distributions from the waitlist to include those currently listed.
>  
> Comments: None
>  
> Timetable for implementation: Immediate
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] implementing RPKI prefix validation actually increases risk

[Scott Leibrand]

This ad hominem attack is uncalled for. Please desist and stick to the
facts, which were very clearly and dispassionately laid out. If you have a
technical or policy solution to the technical problem presented, please
share. If not, casting aspersions on someone for their previously stated
views on unrelated matters instead of engaging with the technical issues is
very disreputable political behavior that should not be allowed on this
list.

-Scott

On Mon, Jun 5, 2023 at 7:45 PM Fernando Frediani 
wrote:

> Hello Michael
>
> If I am not forgotten you are someone who strongly opposed IPv6 sometime
> ago, called it a undue burden and seems to be fighting against it with all
> forces and stating clearly and you don't need it. Not surprised now by your
> email about  RPKI as well.
>
> Fernando
> On 05/06/2023 23:29, Michel Py via ARIN-PPML wrote:
>
> Hi folks,
>
>
>
> I am bumping into a dark side of RPKI prefix validation that actually
> increases risk to the network when deployed.
>
>
>
> As many others here do, I use BGP blackhole feeds (RTBH). This technique
> has been around for a long time.
>
> It is quite a common situation in some orgs to have the in-house SIEM/IDS
> redistribute blackhole prefixes via a BGP feed.
>
> Also, there are numerous publicly available ones such as :
>
>
> https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/
>
> https://www.spamhaus.org/bgpf/
>
> http://arneill-py.sacramento.ca.us/cbbc/
>
>
>
> When configuring RPKI validation, here is what happens. 152.89.196.0/24
> is a real-world example of a prefix that has been blacklisted by three
> different RTBH feeds.
>
> After implementing RPKI validation, it has generated some volume of
> firewall alarms for different type of attacks.
>
>
>
> c4321-michel#sh ip bgp | beg 152.89.196.
>
> BGP table version is 48156064, local router ID is 173.166.233.21
>
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
>
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> RPKI validation codes: V valid, I invalid, N Not found
>
>   Network  Next HopMetric LocPrf Weight Path
>
> I*152.89.196.0/24  192.0.2.10 90  0 21719 I
>  <== Trusted RTBH
>
> N* i   192.0.2.1 100  1 i
><== CBBC
>
> I* 192.0.2.10 40  0 65190 i
>  <== Spamhaus
>
> V*>173.166.233.22 30  0 1299 9002
> 57523 i<== Prefix from full feed
>
>
>
> The problem here is that RPKI validation is at the very top of the BGP
> bestpath decision process, before weight and local-preference, without any
> way to change that.
>
> Therefore, the “Valid” status of the RPKI route affectively renders the
> RTBH feeds useless. No matter what manipulations of other parameters may be
> configured in route-maps, the RPKI status will override everything else.
>
> Unsurprisingly, Cisco says that doing something about it is impossible.
>
>
>
> Unfortunately, the “Valid” RPKI status presents no warranties whatsoever
> that the prefix is not used for rogue activities. Same as HTTPS
> certificates, crooks and spammers have realized that a ROA was a necessary
> part of doing their dirty business.
>
> This particular prefix is a well-known source of attacks; there are very
> valid reasons it is present in multiple BGP blackholes. Unfortunately, RPKI
> validation, combined with Cisco’s implementation, as provided bad actors
> with a tool to disable a blacklisting method that plenty of orgs are
> currently using.
>
>
>
> I am forced to disable RPKI prefix validation. To me, RPKI prefix
> validation does not bring enough value to compensate for the loss of the
> protection that the BGP blackhole feeds provide. Implementing RPKI
> validation has actually increased the volume of attacks on my network,
> attacks that were previously blocked right at the very edge. The risk
> increase is immediate : implementing RPKI validation is what made me look
> at these new firewall alarms. On the other hand, the gain is not
> immediately perceptible.
>
>
>
> In terms of public policy and ARIN, I think that there is a consensus that
> deploying RPKI validation is good for everyone. I am posting this so that
> the community can build an understanding of why it may not be deployed
> universally. I am not deploying it because I don’t want it or don’t
> understand it, I am not deploying it because it simply does not work for
> me. I don’t think I will be the only one in that case. It looked like a
> good idea on paper, but the impossibility to accommodate currently
> implemented security measures is a no-go.
>
>
>
> Michel
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list 

Re: [arin-ppml] Wait List Space - Feedback Requested

[Scott Leibrand]

If the requestor's use case works with sub-/24, they can request it. If
they want a /24, they can request that. I agree there are lots of use cases
for which /24 is a de facto minimum (even for MDN when you have a larger
covering aggregate you can announce). But there are some use cases for
which smaller blocks would be sufficient, and they'll likely become more
common over time as people figure out how to get filters opened for
specific use cases.

Regardless, ARIN shouldn't be in the business of telling requestors what
they need. They should be in the business of fairly assigning the space
they have to those who need it.

-Scott

On Fri, Jan 27, 2023 at 6:15 PM Justin Wilson  wrote:

> The problem is everyone has their filters set to not accept smaller than
> /24s.  It sounds like a simple fix but it’s like herding cats.
>
> Justin
> Sent from my iPhone
>
> On Jan 27, 2023, at 9:03 PM, Scott Leibrand 
> wrote:
>
> 
> IMO orgs who can get by with a smaller block should be able to request one
> (with no lower limit: if they really want a /25, they should be able to ask
> for that). But orgs who receive a block should be removed from the waiting
> list and must reapply to rejoin it, putting them at the back of the list.
>
> Organizations on the waiting list should have their requests filled only
> with a block of the size they request. ARIN should not fulfil a /22 request
> with four /24s, for example. Splitting a block should be fine, though.
>
> So if the next few requests on the list are:
> 1. /24
> 2. /22
> 3. /23
> 4. /25
> 5. /22
> 6. /24
> 7. /25
> and a /22 becomes available, requests 1, 3, 4, and 7 should be fulfilled,
> and requests 2, 5, and 6 should move to the top of the waitlist for the
> next available block.
>
> This will provide a (slight) incentive for organizations to only request
> what they "really" need, as they're likely to get it slightly sooner than
> if they have to wait for a bigger block to become available.
>
> -Scott
>
> On Fri, Jan 27, 2023 at 1:35 PM WOOD Alison * DAS <
> alison.w...@das.oregon.gov> wrote:
>
>>
>>
>>
>>
>> Hello!
>>
>>
>>
>> The Policy Experience Report Working Group has been working on the Policy
>> Experience Report from ARIN 50.  I would appreciate your feedback on the
>> following issue regarding transferring waitlist space.
>>
>>
>>
>> The current wait list criteria is:
>>
>>
>>
>>- Must have a /20 or less in total IPv4 holdings.
>>- May request up to a /22.
>>- Removed from list if IPv4 received via 8.3/8.4 transfer.
>>- Received ip space is eligible for needs-based transfer after five
>>years.
>>
>>
>>
>>
>>
>> The Policy Experience Working Group would like your feedback on a
>> potential policy idea: With waiting list times being in years, should an
>> org be eligible to get a small block (e.g. /24) via 8.3/8.4 and stay on the
>> waiting list?
>>
>>
>>
>>
>>
>> The working group appreciates your feedback.
>>
>>
>>
>> Thank you!
>>
>>
>>
>>
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Wait List Space - Feedback Requested

[Scott Leibrand]

IMO orgs who can get by with a smaller block should be able to request one
(with no lower limit: if they really want a /25, they should be able to ask
for that). But orgs who receive a block should be removed from the waiting
list and must reapply to rejoin it, putting them at the back of the list.

Organizations on the waiting list should have their requests filled only
with a block of the size they request. ARIN should not fulfil a /22 request
with four /24s, for example. Splitting a block should be fine, though.

So if the next few requests on the list are:
1. /24
2. /22
3. /23
4. /25
5. /22
6. /24
7. /25
and a /22 becomes available, requests 1, 3, 4, and 7 should be fulfilled,
and requests 2, 5, and 6 should move to the top of the waitlist for the
next available block.

This will provide a (slight) incentive for organizations to only request
what they "really" need, as they're likely to get it slightly sooner than
if they have to wait for a bigger block to become available.

-Scott

On Fri, Jan 27, 2023 at 1:35 PM WOOD Alison * DAS <
alison.w...@das.oregon.gov> wrote:

>
>
>
>
> Hello!
>
>
>
> The Policy Experience Report Working Group has been working on the Policy
> Experience Report from ARIN 50.  I would appreciate your feedback on the
> following issue regarding transferring waitlist space.
>
>
>
> The current wait list criteria is:
>
>
>
>- Must have a /20 or less in total IPv4 holdings.
>- May request up to a /22.
>- Removed from list if IPv4 received via 8.3/8.4 transfer.
>- Received ip space is eligible for needs-based transfer after five
>years.
>
>
>
>
>
> The Policy Experience Working Group would like your feedback on a
> potential policy idea: With waiting list times being in years, should an
> org be eligible to get a small block (e.g. /24) via 8.3/8.4 and stay on the
> waiting list?
>
>
>
>
>
> The working group appreciates your feedback.
>
>
>
> Thank you!
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy

[Scott Leibrand]

If someone uses a private ASN to announce a route, that route still takes
RIB/FIB space, it just has its origin ASN as the upstream provider's ASN.

-Scott

On Sat, Sep 17, 2022 at 10:22 PM Adam Thompson 
wrote:

> I’m on the fence.
>
>
>
> I think the scarce resource is no longer 16-bit ASNs but is now FIB space
> on routers.  I even know of a few where RIB space is the issue, not FIB.
> We’re not – that I know of – about to hit another 512k day or similar in
> the next six months, but there are a lot of routers out there that can only
> handle 1M IPv4-sized routes.
>
>
>
> I agree with your logic (the comparison to RFC1918) but I am concerned
> about an explosion of ASNs and corresponding routes.  I’m assuming an
> explosion of ASNs will equate an explosion of routes, v4 and/or v6, as
> otherwise, why would you need a public ASN?
>
>
>
> Separately, I don’t see anything wrong with the modifications proposed in
> the Staff Review – they seem sound, although I wish the full proposed
> rewritten section had been included, in addition to the item-wise
> commentary.
>
>
>
> -Adam
>
>
>
> *Adam Thompson*
>
> Consultant, Infrastructure Services
>
> [image: MERLIN]
>
> 100 - 135 Innovation Drive
>
> Winnipeg, MB R3T 6A8
>
> (204) 977-6824 or 1-800-430-6404 (MB only)
>
> https://www.merlin.mb.ca
>
> Chat with me on Teams
> <https://teams.microsoft.com/l/chat/0/0?users=athomp...@merlin.mb.ca>
>
>
>
> *From:* ARIN-PPML  *On Behalf Of *Scott
> Leibrand
> *Sent:* September 13, 2022 12:20 PM
> *To:* ARIN 
> *Cc:* PPML 
> *Subject:* Re: [arin-ppml] Revised - Draft Policy ARIN-2022-2: Remove
> Barrier to BGP Uptake in ASN Policy
>
>
>
> I support this.
>
> Scott
>
>
>
> On Sep 13, 2022, at 7:46 AM, ARIN  wrote:
>
> 
>
> The following Draft Policy has been revised:
>
>
>
> * ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy
>
>
>
> Revised text is below and can be found at:
>
>
>
> https://www.arin.net/participate/policy/drafts/2022_2/
>
>
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion 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/participate/policy/pdp/
>
>
>
> Draft Policies and Proposals under discussion can be found at:
>
> https://www.arin.net/participate/policy/drafts/
>
>
>
> Regards,
>
>
>
> Sean Hopkins
>
> Senior Policy Analyst
>
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
>
>
>
> Draft Policy ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy
>
>
>
> Problem Statement:
>
>
>
> The current requirements for getting an ASN have resulted in confusion
> particularly for new entrants, who have their hands more than full with the
> mechanics of getting BGP up and running. The availability of 32 bit ASNs
> provides an opportunity for the removal of unnecessary constraints and
> processes for the allocation of  ASNs.
>
>
>
> ARIN does not provide guidance to use RFC1918 space if possible and
> likewise ARIN should not require the use of private ASNs in preference to
> public ASNs.
>
>
>
> Further Technical Rationale:
>
>
>
> Four octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has
> taken several years for routing equipment in general use to catch up, but
> today 32 bit ASNs are generally accepted and it is rare that an
> organization which has been issued a 32 bit ASN comes back to ARIN and says
> they need a 16 bit ASN instead.
>
>
>
> The austerity measure of requiring extensive documentation to get an ASN
> is left over from the days of 16 bit ASNs (total space 65000). It is no
> longer appropriate and we should align our conservation requirements with
> those found in other 32-bit spaces (total space four billion). Consider:
>
>
>
> A /32 of IPv6 space is the default allocation and will be assigned to any
> ISP that requests it.
>
>
>
> Temporary assignment of a /32 of IPv4 space can be acquired on most
> residential ISPs by issuing a DHCP request.
>
>
>
> We propose making issuance of the first 32 bit ASN for any ORGID (or each
> site for organizations that have number resources under multiple discrete
> networks policy) be pro-forma upon

Re: [arin-ppml] Revised - Draft Policy ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy

[Scott Leibrand]

I support this. 

Scott

> On Sep 13, 2022, at 7:46 AM, ARIN  wrote:
> 
> 
> The following Draft Policy has been revised:
>  
> * ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy
>  
> Revised text is below and can be found at:
>  
> https://www.arin.net/participate/policy/drafts/2022_2/
>  
> You are encouraged to discuss all Draft Policies on PPML. The AC will 
> evaluate the discussion 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/participate/policy/pdp/
>  
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>  
> Regards,
>  
> Sean Hopkins
> Senior Policy Analyst
> American Registry for Internet Numbers (ARIN)
>  
>  
>  
>  
> Draft Policy ARIN-2022-2: Remove Barrier to BGP Uptake in ASN Policy
>  
> Problem Statement:
>  
> The current requirements for getting an ASN have resulted in confusion 
> particularly for new entrants, who have their hands more than full with the 
> mechanics of getting BGP up and running. The availability of 32 bit ASNs 
> provides an opportunity for the removal of unnecessary constraints and 
> processes for the allocation of  ASNs.
>  
> ARIN does not provide guidance to use RFC1918 space if possible and likewise 
> ARIN should not require the use of private ASNs in preference to public ASNs.
>  
> Further Technical Rationale:
>  
> Four octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has taken 
> several years for routing equipment in general use to catch up, but today 32 
> bit ASNs are generally accepted and it is rare that an organization which has 
> been issued a 32 bit ASN comes back to ARIN and says they need a 16 bit ASN 
> instead.
>  
> The austerity measure of requiring extensive documentation to get an ASN is 
> left over from the days of 16 bit ASNs (total space 65000). It is no longer 
> appropriate and we should align our conservation requirements with those 
> found in other 32-bit spaces (total space four billion). Consider:
>  
> A /32 of IPv6 space is the default allocation and will be assigned to any ISP 
> that requests it.
>  
> Temporary assignment of a /32 of IPv4 space can be acquired on most 
> residential ISPs by issuing a DHCP request.
>  
> We propose making issuance of the first 32 bit ASN for any ORGID (or each 
> site for organizations that have number resources under multiple discrete 
> networks policy) be pro-forma upon request. If an org’s technical people 
> think they need a public ASN, they probably do!
>  
> Policy statement:
>  
> Replace the entirety of Section 5, which currently reads:
>  
> There are a limited number of available Autonomous System Numbers (AS 
> Numbers), therefore, it is important to determine which sites require unique 
> ASNs and which do not. If a unique ASN is not required for a given network 
> design, one or more of the ASN reserved for private use should be utilized. 
> Those numbers are: 64512 through 65534 and 42 through 4294967294 
> inclusive.
>  
> In order to be assigned an ASN, each requesting organization must provide 
> ARIN with verification that it requires a unique routing policy, such as a 
> plan:
>  
> To originate announcement of IP Number Resources via an accepted protocol 
> (such as Border Gateway Protocol) from an ASN different than that of its 
> upstream provider;
>  
> To multihome a site with one or more Autonomous Systems; or
>  
> To use an ASN to interconnect with other Autonomous Systems.
>  
> ASNs are issued based on current need, as set out in this section 5.
>  
> With the following new Section 5:
>  
> Any organization may be issued a single Autonomous System Number (ASN) upon 
> request. Organizations that have space issued under Multiple Discrete 
> Networks policy may be issued one ASN per discrete network upon request.
>  
> Additional ASN requests should include proof of the requestor's need for a 
> unique routing policy, or other technical justification for the need for more 
> than one ASN.
>  
> Timetable for implementation: Immediate
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:

Re: [arin-ppml] Draft Policy ARIN-2022-9: Leasing Not Intended

[Scott Leibrand]

No, this draft policy is not merely a clarification. This would a
significant change in policy, and if enforced would significantly interfere
with the efficient operation of the Internet.

ARIN should only care whether addresses are in use on an operational
network. They have no reason to care about the connectivity, or lack
thereof, between an LIR and operational networks that it reallocates or
reassigns space to.

I run an operational network. We still use a number of address blocks
originally allocated to us by our transit providers before we acquired our
own space, which we have always announced in BGP in a multihomed fashion.
If we stop announcing the route to the transit provider who announced us
the space, whether temporarily (due to an outage or maintenance) or more
permanently (because we no longer need transit from them there), we should
be able to continue using our assigned space as long as we have appropriate
contractual arrangements in place to do so. That is a form of "leasing"
that has always been allowed, and this policy would disallow it.

Any policy requiring a certain form of connectivity between an LIR and its
customers will either be unenforceable and easily gamed, or onerous,
bureaucratic, and will interfere with the legitimate operation of networks
efficiently utilizing their IPv4 space.

-Scott

On Wed, Aug 24, 2022 at 9:32 AM Fernando Frediani 
wrote:

> Hello Scott
>
> Could you explain better the arguments you are against in this proposal or
> that don't sound valid?
>
> All this proposal does is to make clear make something clear in the policy
> text.
> If you cannot go to ARIN and justify that you intend to use requested IP
> addresses for simple leasing proposes, to be leased to organization with
> who you don't provide any connectivity services, why would it be an
> accepted thing in any other scenario ?
> IP space is to be used for building Internet infrastructure and to get
> customers connected to the Internet, not to be simply leased from one
> organization pretending to be a RIR to another.
>
> Unless I misunderstood and you like the idea of leasing and so why you
> oppose this proposal.
>
> Regards
> Fernando
> On 24/08/2022 12:40, Scott Leibrand wrote:
>
> Opposed. There is no good reason I am aware of for ARIN to require the
> bundling of IP addressing and connectivity services. The arguments provided
> in this draft policy are not sound or valid ones.
>
> Scott
>
> On Aug 23, 2022, at 9:28 AM, ARIN   wrote:
>
> 
>
> On 18 August 2022, the ARIN Advisory Council (AC) accepted "ARIN-prop-308:
> Leasing Not Intended" as a Draft Policy.
>
>
>
> Draft Policy ARIN-2022-9 is below and can be found at:
>
>
>
> https://www.arin.net/participate/policy/drafts/2022_9/
>
>
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion 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/participate/policy/pdp/
>
>
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>
>
>
> Regards,
>
>
>
> Sean Hopkins
>
> Senior Policy Analyst
>
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
> Draft Policy ARIN-2022-9: Leasing Not Intended
>
>
>
> Problem Statement:
>
>
>
> “IPv6 Policy (section 6.4.1.) explicitly mention that address space is not
> a property. This is also stated in the RSA (section 7.) for all the
> Internet Number Resources.
>
>
>
> However, with the spirit of the IPv4 allocation policies being the same,
> there is not an equivalent text for IPv4, neither for ASNs.
>
>
>
> Further to that, policies for IPv4 and IPv6 allocations, clearly state
> that allocations are based on justified need and not solely on a predicted
> customer base. Similar text can be found in the section related to
> Transfers (8.1).
>
>
>
> Consequently, resources not only aren’t a property, but also, aren’t
> allocated for leasing purposes, only for justified need of the resource
> holder and its directly connected customers.
>
>
>
> Therefore, and so that there are no doubts about it, it should be made
> explicit in the NRPM that the Internet Resources should not be leased “per
> se”, but only as part of a direct connectivity service. At the same time,
> section 6.4.1. should be 

Re: [arin-ppml] Draft Policy ARIN-2022-9: Leasing Not Intended

[Scott Leibrand]

Opposed. There is no good reason I am aware of for ARIN to require the bundling 
of IP addressing and connectivity services. The arguments provided in this 
draft policy are not sound or valid ones.  

Scott

> On Aug 23, 2022, at 9:28 AM, ARIN  wrote:
> 
> 
> On 18 August 2022, the ARIN Advisory Council (AC) accepted "ARIN-prop-308: 
> Leasing Not Intended" as a Draft Policy.
>  
> Draft Policy ARIN-2022-9 is below and can be found at:
>  
> https://www.arin.net/participate/policy/drafts/2022_9/
>  
> You are encouraged to discuss all Draft Policies on PPML. The AC will 
> evaluate the discussion 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/participate/policy/pdp/
>  
> Draft Policies and Proposals under discussion can be found at: 
> https://www.arin.net/participate/policy/drafts/
>  
> Regards,
>  
> Sean Hopkins
> Senior Policy Analyst
> American Registry for Internet Numbers (ARIN)
>  
>  
> Draft Policy ARIN-2022-9: Leasing Not Intended
>  
> Problem Statement:
>  
> “IPv6 Policy (section 6.4.1.) explicitly mention that address space is not a 
> property. This is also stated in the RSA (section 7.) for all the Internet 
> Number Resources.
>  
> However, with the spirit of the IPv4 allocation policies being the same, 
> there is not an equivalent text for IPv4, neither for ASNs.
>  
> Further to that, policies for IPv4 and IPv6 allocations, clearly state that 
> allocations are based on justified need and not solely on a predicted 
> customer base. Similar text can be found in the section related to Transfers 
> (8.1).
>  
> Consequently, resources not only aren’t a property, but also, aren’t 
> allocated for leasing purposes, only for justified need of the resource 
> holder and its directly connected customers.
>  
> Therefore, and so that there are no doubts about it, it should be made 
> explicit in the NRPM that the Internet Resources should not be leased “per 
> se”, but only as part of a direct connectivity service. At the same time, 
> section 6.4.1. should be moved to the top of the NRPM (possibly to section 1. 
> “Principles and Goals of the American Registry for Internet Numbers (ARIN)”.”
>  
> Policy statement:
>  
> Actual Text (to be replaced by New Text):
>  
> 6.4.1. Address Space Not to be Considered Property
>  
> It is contrary to the goals of this document and is not in the interests of 
> the Internet community as a whole for address space to be considered freehold 
> property.
>  
> The policies in this document are based upon the understanding that 
> globally-unique IPv6 unicast address space is allocated/assigned for use 
> rather than owned.
>  
> New Text
>  
> 1.5. Internet Number Resources Not to be Considered Property
>  
> It is contrary to the goals of this document and is not in the interests of 
> the Internet community as a whole for address space to be considered freehold 
> property.
>  
> The policies in this document are based upon the understanding that Internet 
> Number Resources are allocated/assigned for use rather than owned.
>  
> ARIN allocate and assign Internet resources in a delegation scheme, with an 
> annual validity, renewable as long as the requirements specified by the 
> policies in force at the time of renewal are met, and especially the 
> justification of the need.
>  
> Therefore, the resources can’t be considered property.
>  
> The justification of the need, generically in the case of addresses, implies 
> their need to directly connect customers. Therefore, the leasing of addresses 
> is not considered acceptable, nor does it justify the need, if they are not 
> part of a set of services based, at least, on direct connectivity.
>  
> Even in cases of networks not connected to the Internet, the leasing of 
> addresses is not admissible, since said sites can request direct assignments 
> from ARIN and even in the case of IPv4, use private addresses or arrange 
> transfers.
>  
> Timetable for implementation: Immediate
>  
> Situation in other Regions:
>  
> In other RIRs, the leasing of addresses is not authorized either and since it 
> is not explicit in their policy manuals either, this proposal will be 
> presented as well.
>  
> Nothing is currently mentioned in RIPE about this and it is not acceptable as 
> a justification of the need. In AFRINIC, APNIC and LACNIC, the staff has 
> confirmed that address leasing is not considered as valid for the 
> justification.
>  
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:

Re: [arin-ppml] Draft Policy ARIN-2022-8: Streamlining Section 11 Policy Language

[Scott Leibrand]

Why are we switching from “number resources” to “numbering resources”? Numbering isn’t an adjective AFAIK. ScottOn Jul 26, 2022, at 5:18 PM, Andrew Dul  wrote:
  

  
  
Attached is a redline pdf and resultant
  text after update which helps show the changes which have been
  suggested to update section11.


Thanks in advance for your feedback on
  this draft.


Andrew



On 7/26/2022 2:37 PM, ARIN wrote:


  
  
  
  
On 21 July 2022, the ARIN Advisory Council
  (AC) accepted "ARIN-prop-316: Streamlining Section 11 Policy
  Language" as a Draft Policy.
 
Draft Policy ARIN-2022-8 is below and can
  be found at:
 
https://www.arin.net/participate/policy/drafts/2022_8/

 
You are encouraged to discuss all Draft
  Policies on PPML. The AC will evaluate the discussion 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/participate/policy/pdp/
 
Draft Policies and Proposals under
  discussion can be found at: https://www.arin.net/participate/policy/drafts/
 
Regards,
 
Sean Hopkins
Senior Policy Analyst
American Registry for Internet Numbers
  (ARIN)
 
 
 
Draft Policy ARIN-2022-8: Streamlining
  Section 11 Policy Language   
 
Problem Statement:
 
Section 11 of the NRPM contains a great
  deal of language that is either explicitly not policy, or is
  not impactful on ARIN’s administration of Internet number
  resources for experimental allocations, or to the customers
  requesting said resources. A revision to transform Section 11
  into a collection of policies for experimental allocations
  serves to make the Section more easily digested by the reader,
  and a more functional reference for customers and ARIN staff
  during experimental allocation requests.
 
Policy statement:
 
Section 11 overview
 
Current text:
 
Experimental Internet Resource Allocations
 
ARIN will allocate Numbering Resources to
  entities requiring temporary Numbering Resources for a fixed
  period of time under the terms of recognized experimental
  activity.
 
“Numbering Resources” refers to unicast
  IPv4 or IPv6 address space and Autonomous System numbers. The
  following are the criteria for this policy:
 
Proposed text:
 
ARIN will allocate Numbering Resources to
  entities requiring temporary Numbering Resources for a fixed
  period of time under the terms of recognized experimental
  activity. “Numbering Resources” refers to unicast IPv4 or IPv6
  address space and Autonomous System numbers.
 
The following are the criteria for this
  policy:
 
Section 11.1
 
Current text:
 
11.1. Documentation of Recognized
  Experimental Activity
 
A Recognized Experimental Activity is one
  where the experiment’s objectives and practices are described
  in a publicly accessible document. It is a normal requirement
  that a Recognized Experimental Activity also includes the
  undertaking that the experiment’s outcomes be published in a
  publicly accessible document at the end of the experiment. The
  conditions for determining the end of the experiment are to be
  included in the document. Applicants for an experimental
  allocation are expected to demonstrate an understanding that
  when the experiment ends, the allocation will be returned; a
  successful experiment may need a new allocation under normal
  policies in order to continue in production or commercial use,
  but will not retain the experimental allocation.
 
A “publicly accessible document” is a
  document that is publicly and openly available free of charges
  and free of any constraints of disclosure.
 
ARIN will not recognize an experimental
  activity under this policy if the entire research experiment
  cannot be publicly disclosed.
 
ARIN has a strong preference for the
  recognition of experimental 

Re: [arin-ppml] Draft Policy ARIN-2021-8: Deprecation of the 'Autonomous System Originations' Field

[Scott Leibrand]

IMO there is a need for number resource holders to be able to attest (solely) 
that a given origin ASN is (solely) authorized to announce route(s) for those 
number resources.  

Most forms of RPKI, like DNSSEC, are really easy to screw up in such a way that 
you knock your own services off the Internet. As long as that remains true, it 
will likely never get to 100% adoption. If it does, it will be because it 
allows number resource holders to make attestations via the RIRs as to who is 
authorized to announce their route(s), without requiring the resource holders 
to sign their route announcements in such a way that screwing up key rotation 
will cause them to be rejected. 

Fully authenticated IRR solutions can provide all the same services that 
putting an origin ASN into whois provides, but only for non-legacy resources. 
Until ARIN is willing to provide basic authenticated IRR services to legacy 
resource holders, it seems we still need the origin ASN field as long as it 
continues to be used. 

Scott

> On Apr 26, 2022, at 9:07 PM, James Hulce via ARIN-PPML  
> wrote:
> 
> snipped, with inline comments
>> On Tue, Apr 26, 2022 at 1:07 PM Job Snijders via ARIN-PPML
>>  wrote:
>> I'm the one who initiated the process towards ARIN-2021-8. I've put in
>> considerable effort to find a purpose and use for the ARIN Originations
>> field in automated tool chains, and ultimately concluded the field has
>> so many apparent challenges it might be better to get rid of it,
>> especially since IRR and RPKI nowadays exist.
> Job, thanks for coming here to explain your perspective. I, for one,
> was surprised to see your name attached to the original policy
> proposal given all of your past work in this space.
> 
>>> On Tue, Apr 26, 2022 at 11:53:58AM -0500, David Farmer via ARIN-PPML wrote:
>>> While I do not support the deprecation of the 'Autonomous System
>>> Originations' Field from the database at this time for many of the reasons
>>> discussed at the microphone at ARIN 49.
>> 
>> Unfortunatey, I wasn't there. Would you be so kind to outline the many
>> reasons in an email?
> My comment: Oppose this proposal at this time. The Autonomous System
> Origination field in ARIN Whois occupies a peculiar yet potentially
> valuable place in the routing information landscape. It provides an
> easy and authenticated way for everyone, including legacy resource
> holders, to communicate their routing intentions. OriginAS does not
> suffer from other problems associated with IRR, such as proxy records
> or multiple disparate databases. Several organizations, networks, and
> exchanges report using the OriginAS field to generate filters and
> perform other operational tasks despite consumption issues. Without
> much known about its uptake, usage, accuracy, and role, deprecation
> would be premature.  (generally summarized my PPML post from last
> week)
> 
> Attempting to outline what others said:
> There was general agreement around the point that ARIN Whois OriginAS
> is a unique, weird legacy thing and should go away eventually. There
> is a desire to eventually reach RPKI's promised land and retire all of
> the earlier outmoded and problematic routing information sources.
> However, we are not there yet. People from several organizations,
> including Lumen (nee CenturyLink & Level 3) and Internet2, expressed
> current operational dependencies. It has notable LOA use cases.
> Several commentators floated a three-year wind-down period as part of
> a broader transition to RPKI and authenticated IRR. I agree with that.
> OriginAS is intertwined with other ongoing ARIN discussions, including
> handling legacy resources and a la carte/standalone vs bundled
> registry services. Right now, there's a vast ocean of legacy resource
> holders locked out of ARIN's IRR and RPKI because they can't or won't
> sign an LRSA. This pool is gradually decreasing, but will be a
> consideration for a while yet. How do legacy resource holders proceed
> if/when OriginAS goes away?
> Those who were in attendance or watching: did I miss anything?
> 
>>> Nevertheless, as discussed in the problem statement this field has
>>> several problems and it eventually needs to be deprecated. However,
>>> since this is an optional field within the ARIN database, without any
>>> enforcement actions required by policy, it seems possible to remove
>>> section 3.5 from the NRPM at this time, without also deprecating the
>>> field at this time.
>>> 
>>> Further, this would set things up for the future deprecation of the
>>> 'Autonomous System Originations' Field from the database to proceed when
>>> the community feels that is appropriate, as expressed through a separate
>>> ARIN Consultation Process, without necessitating additional policy actions.
>>> 
>>> If this policy proposal were modified to only remove section 3.5 from the
>>> NRPM at this time, with the deprecation of the 'Autonomous System
>>> Originations' Field from the database occurring at some future 

Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilization for Future Allocations

[Scott Leibrand]

On Fri, Mar 18, 2022 at 12:39 PM Mike Burns  wrote:

> Hi Scott,
>
>
>
> I am sorry, I actually penned a long reply to  your initial post but never
> sent it.
>
> The limit on initial block size is the same as if you came to ARIN seeking
> a block not for lease, but for your circuit-connected customers. To wit,
> ARIN will require more than just your statement.
>
> What’s to stop a company from claiming they will be delivering service to
> connected clients over the next two years, so they should get a
> pre-approval?
>

They have to buy equipment and sign contracts for transit to deliver such
service. That equipment is worth far less if re-sold, and those contracts
cost money to terminate.

If literally the only thing I have to purchase to start an IP leasing
company is the addresses themselves, and I expect the addresses to continue
appreciating in value, then I am incentivized to buy the largest block I
can and provide ARIN with extremely optimistic (but not fraudulent) sales
projections showing how I plan to lease it all out. If I fail to lease the
space out as fast as my optimistic plans, I still make a healthy profit on
any price appreciation.

One way to address this might be to require that the documentation to be
provided to ARIN which details the use of at least 50% of the requested
IPv4 block be in the form of binding contracts if the IPv4 space is
intended for reassignment to customers. That way, a speculative lessor can
only start with a /24 or 2x as much IP space as they've already signed up
customers for, and then can come back to ARIN to transfer more as soon as
their customers have efficiently utilized at least 50% of their cumulative
IPv4 space.

If that's the approach we want to take, I think we'd need to modify the
policy to stipulate that.


>
> The initial size for a section 8 transfer per 8.5.5 is a /24. To get a
> larger initial block, evidence is required that should be equivalent in
> scope and detail regardless of whether the anticipated clients are
> connected with a circuit or not. Are we seeing such fraud by ISPs to
> increase their purchase size?
>
>
>
> Finally, if you attest to fraudulent information, you are taking liability
> risks that also dampen speculation.
>
>
>
> Regards,
>
> Mike
>
> PS You ignored my request for evidence of speculation at RIPE where
> absolutely no needs demonstration has been required for many years. 
>

It won't discuss in public whether I have observed speculation first-hand,
but I will say that all transactions I'm aware of were above-board and
policy-compliant. I do agree, though, that pure financial speculation is
not driving the overall market price for addresses beyond the difference
between prices for RIPE vs. ARIN space (which is minimal). If the choice
were between RIPE's (lack of) policy and ARIN's current no-leasing-allowed
policy, I'd likely choose RIPE's. But I think a leasing-allowed policy that
limits initial block size and then allows additional transfers based on 50%
utilization would be better than both of those.

-Scott


>
>
>
>
>
>
>
>
>
>
> *From:* Scott Leibrand 
> *Sent:* Friday, March 18, 2022 3:25 PM
> *To:* Mike Burns 
> *Cc:* Owen DeLong ; Andrew Dul ;
> arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Revised and Retitled - Draft Policy
> ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining
> Utilization for Future Allocations
>
>
>
>
>
> On Mar 18, 2022, at 7:37 AM, Mike Burns  wrote:
>
> 
>
> Hi Owen, Andrew, and Scott,
>
>
>
> Transfer approval of a larger-than-minimum block size requires detailed
> documentation of the use of at least 50% of the block in 24 months, and
> that detailed documentation must be officer-attested.  I’m sure we all
> agree that nobody can approach ARIN for a large initial block without
> providing believable documentation to ARIN, and the attestation provides
> actionability against fraud.
>
>
>
> I don’t doubt that believable documentation is required. But my concern,
> as I stated in the very first reply to this thread that everyone ignored,
> is:
>
>
>
> If you’re going to remove that, what is to stop me from opening a new LIR
> and stating that I want pre-qualification for a transfer of a /8 to lease
> out, because I have sales projections that I can lease out a /9 within 24
> months, a /10 within 12 months, and a /11 within 6 months? And if I fail to
> meet my sales projections, I can sell some or all of the /8 after 12 months
> (presumably at a profit, as prices just keep going up).
>
>
>
> It seems that there should be some limit on initial block size if we’re
> going to rely exclusively on recipients’ leasing projections instead of
> requiring use on an operational network.
>
&g

Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilization for Future Allocations

[Scott Leibrand]

> On Mar 18, 2022, at 7:37 AM, Mike Burns  wrote:
> 
> 
> Hi Owen, Andrew, and Scott,
>  
> Transfer approval of a larger-than-minimum block size requires detailed 
> documentation of the use of at least 50% of the block in 24 months, and that 
> detailed documentation must be officer-attested.  I’m sure we all agree that 
> nobody can approach ARIN for a large initial block without providing 
> believable documentation to ARIN, and the attestation provides actionability 
> against fraud. 

I don’t doubt that believable documentation is required. But my concern, as I 
stated in the very first reply to this thread that everyone ignored, is:

> If you’re going to remove that, what is to stop me from opening a new LIR and 
> stating that I want pre-qualification for a transfer of a /8 to lease out, 
> because I have sales projections that I can lease out a /9 within 24 months, 
> a /10 within 12 months, and a /11 within 6 months? And if I fail to meet my 
> sales projections, I can sell some or all of the /8 after 12 months 
> (presumably at a profit, as prices just keep going up).  
> 
> It seems that there should be some limit on initial block size if we’re going 
> to rely exclusively on recipients’ leasing projections instead of requiring 
> use on an operational network.


I take your point about a /8 being infeasible to acquire on the market, but the 
same point applies at whatever the maximum available size currently is. 

-Scott

> Further transfers require proof of utilization of the original transfers.
>  
> This persistent fear of “speculation”, whatever that word means in this 
> context, is belied by the RIPE experience. Will somebody please answer the 
> RIPE experience before bringing up the “speculation” argument?
> It’s over 10 years now. The experiment has been performed. We have the data. 
> It’s time to point to evidence instead of holding policy in thrall to 
> assertions of the dangers of speculation.
>  
> Remember the biggest damper on speculation is the reality of the market. You 
> can’t just whip up a /8 to be transferred, and if you could, you are looking 
> at spending almost a billion dollars! Do you really think a billion dollar 
> investment in an asset that all the smart people say will be valueless at 
> some point isn’t a damper on speculation? Do you think ARIN would approve an 
> initial transfer of a /8 on the mere promise it will be leased out in two 
> years?
>  
> I trust the market and I trust ARIN staff enough to dampen “speculation”. As 
> always, should something damaging appear, we retain the ability to change 
> policy.
>  
> Regards,
> Mike
>  
>  
> From: ARIN-PPML  On Behalf Of Owen DeLong via 
> ARIN-PPML
> Sent: Thursday, March 17, 2022 8:20 PM
> To: Andrew Dul 
> Cc: arin-ppml@arin.net
> Subject: Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: 
> Permit IPv4 Leased Addresses for Purposes of Determining Utilization for 
> Future Allocations
>  
> I favor the kind of limitations Scott has expressed. I was commenting on the 
> arguments made by Fernando and have not yet had the bandwidth to review the 
> actual policy text in detail.
>  
> Owen
>  
> 
> 
> On Mar 17, 2022, at 16:17 , Andrew Dul  wrote:
>  
> The draft policy as currently written does not provide any additional limits 
> against speculation.  As drafted, it allows any organization (including those 
> who do not operate networks) to obtain IPv4 addresses for the purpose of 
> leasing.  
>  
> With that policy change what types of limits does the community think would 
> be needed?
>  
> Thanks,
> Andrew
>  
> On 3/17/2022 3:00 PM, Scott Leibrand wrote:
> +1 to both Owen and David Farmer's comments. Leasing IPv4 space is likely the 
> best solution for some networks that need those addresses to operate their 
> network. If an organization wants to acquire and lease out IPv4 space without 
> providing bundled IPv4 transit, that should be allowed by policy. It might be 
> useful for ARIN policy to try to slightly dampen speculation by requiring 
> that organizations seeking to acquire large blocks of IPv4 space demonstrate 
> that their current holdings are being efficiently used by the organization 
> they're registered to in whois. I am not sure if this policy proposal does 
> that to my satisfaction, but once we ensure it does so, I would likely 
> support it.
>  
> -Scott
>  
> On Thu, Mar 17, 2022 at 1:33 PM Owen DeLong via ARIN-PPML 
>  wrote:
>  
> 
> 
> On Mar 16, 2022, at 15:22 , Fernando Frediani  wrote:
>  
> Hi David
> If I understand correctly you seem to have a view that there should be a ARIN 
> policy to permit IPv4 leasing just because it is a reality and we kin

Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilization for Future Allocations

[Scott Leibrand]

+1 to both Owen and David Farmer's comments. Leasing IPv4 space is likely
the best solution for some networks that need those addresses to operate
their network. If an organization wants to acquire and lease out IPv4 space
without providing bundled IPv4 transit, that should be allowed by policy.
It might be useful for ARIN policy to try to slightly dampen speculation by
requiring that organizations seeking to acquire large blocks of IPv4 space
demonstrate that their current holdings are being efficiently used by the
organization they're registered to in whois. I am not sure if this policy
proposal does that to my satisfaction, but once we ensure it does so, I
would likely support it.

-Scott

On Thu, Mar 17, 2022 at 1:33 PM Owen DeLong via ARIN-PPML <
arin-ppml@arin.net> wrote:

>
>
> On Mar 16, 2022, at 15:22 , Fernando Frediani 
> wrote:
>
> Hi David
>
> If I understand correctly you seem to have a view that there should be a
> ARIN policy to permit IPv4 leasing just because it is a reality and we kind
> of have to accept it in our days. No we don't, and that's for many
> different reasons.
>
> Well, of course, you are free to deny reality as much as you want. Many
> people do. It’s not particularly helpful in the discussion, however.
>
> I am used to see people saying the brokers are doing a good thing for the
> community by facilitating the things which in reality is the opposite. It
> may look like a good things, but the real beneficiaries are only them who
> profit from it without much concern of what is fair or not to most
> organizations involved.
>
>
> You are actually mistaken here. I used to think as you do, actually. I was
> very resistant to the first “specified transfer” policies because of some
> of the reasons you describe. However, what you are failing to recognize is
> that:
> + Brokers and specified transfers were going to happen with or without
> the RIRs. If they happened without the RIRs,
> there’d be no accurate record of who was using which address space and the
> provenance of addresses would be
> very difficult to support or defend.
>
> * Benefit to the community from brokers: (ethical) brokers are familiar
> with the rules in the RIRs in which
> they operate and can assist their customers in accurate and compliant
> registration updates and
> aid in keeping the allocation database(s) accurate.
>
> + With the economic realities of IPv4 addresses becoming progressively
> more and more expensive and the advent
> of ISPs with limited IPv4 resources available, it is inevitable that more
> and more IP service providers will be
> doing one or more of the following:
>
> + Separate surcharges for IPv4 addresses
> + Expecting customers to supply their own IPv4 addresses
> + Surcharges for IPv4 services
> + IPv4 “installation charges” large enough to cover the procurement of
> addresses
>
> * Brokers assist ISPs and customers in many of the above circumstances.
>
> + With a variety of organizations holding IPv4 addresses that may or may
> not even known they have them and whose
> IPv4 resources may vastly exceed their needs, it is (arguably) desirable
> to have those addresses be transferred to parties
> that have current need for IPv4 addresses.
>
> * Brokers provide a valuable service to the community identifying and
> marketing these resources
> * Paid transfers provide an incentive for entities to make more efficient
> use of the resources they have in order
> to monetize the resources they no longer need. Brokers are frequently able
> to assist in this process.
>
> + With the high cost of acquisition, IPv4 addresses have become a capital
> intensive part of any network-dependent
> business model that must support IPv4. Further, there is some risk that
> this capital outlay may be fore a resource
> which will abruptly and quickly lose its value and no longer be needed
> well before it can be amortized as a capital
> expenditure. As such, it may make sense for some entities to transfer that
> risk to another organization by using
> a lease structure instead of purchasing the addresses outright.
>
> * Brokers that provide IPv4 leasing in an ethical and policy compliant
> way provide a valuable service
> to these businesses. Yes, their price per address may eventually be more
> than it would have cost
> them to purchase the addresses, but the same is true of virtually any
> rental situation.  On the other hand,
> that excess helps offset the risk that the lessor is taking by owning a
> resource that may or may not remain
> valuable and may or may not continue to produce revenue.
>
> IP Leasing is very different from IP Transfer which I see not problem they
> continue doing it. IP Transfer at least we have some guarantees that the
> directly receiving organization really justify for them and that is a quiet
> important (I would say fundamental) point to look at, because that is
> fairer to everyone involved. What guarantees we have when a IP Leasing is
> done in that sense, that fairness 

Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilization for Future Allocations

[Scott Leibrand]

It seems that lots of people oppose this policy based on their assumptions
about what it will do to the economics of the IP address transfer market,
but no one is making those assumptions explicit or describing what exactly
they think would happen if it were passed.

Right now https://auctions.ipv4.global/prior-sales is showing recent prices
of about $55 per IP (to buy them on the transfer market), up from about
$30/IP a year ago.

Right now https://www.heficed.com/lease-ipv4/ is quoting $0.50/mo per IP
($546 for 1024 addresses). The data at
https://www.ipxo.com/blog/leasing-vs-buying-ip-addresses/ is a bit older,
but indicates that in late 2020, prices were in a similar range of $0.34 -
$0.67 per IP.

If someone buys addresses at $55 each and leases them out at $0.50/mo, it
would take 110 months (9 years) to cover the cost. That would be a lousy
business, so clearly, entities leasing space are expecting IPv4 purchase
prices to continue rising more quickly than their cost of financing, and
expect to be able to sell any addresses they buy at a profit.

Leasing is clearly already happening. Right now it has to be done using
RIPE space or by an entity that has (at least nominal) network connectivity.

If you oppose or support this policy on grounds that it will affect the
supply and demand of addresses, can you be more specific as to what effects
you expect relaxing the justification requirements for those offering IP
leasing who want to buy more space to lease out would have? How would this
policy affect the demand and price of IPv4 addresses bought and sold on the
transfer market? How would that affect the supply, demand, and price of
IPv4 addresses available for lease? How would that affect network
operators? Would more of them switch from purchasing addresses to leasing
them? With leasing (currently) being cheaper than purchasing (because a
purchase is also an investment in a currently-appreciating asset), would it
help or hurt network operators for leasing to be considered a more
legitimate option?

-Scott

On Fri, Mar 11, 2022 at 10:02 AM Fernando Frediani 
wrote:

> On 11/03/2022 14:56, Tom Fantacone wrote:
>
> Bill,
>
> We can quibble about semantics, but let's go with your verbiage:
>
> If I run a network and qualify for an /18 right now, can I go to ARIN and
> lease one?   I must either *pay someone to release their addresses to
> ARIN to lease to me* or lease one from a (non-ARIN) 3rd party.
>
> And that should always be the expected, release them to ARIN which should
> be the only actor taking care of it.
> I really fail to understand how can one consider legit that a 3rd party
> could be doing this job otherwise.
>
> If everybody sticks that what is expected, things work better, is much
> better to trust ARIN to do this plus in the end doing in such way doesn't
> least space for speculation, price rises and community have the assurance
> that the one who is intermediating it is someone really neutral and with no
> other interests to the business other than make sure the policies are being
> followed.
>
> Fernando
>
>
> And the amount I must pay (commonly referred to as the Purchase Price in
> most IPv4 transfer contracts, whether I'm technically "buying" it or not),
> is significantly more than either typical lease rates or ARIN's annual
> fees.  My point is that 3rd party lessors do provide a service that ARIN
> does not.
>
> Regards,
>
> Tom Fantacone
>
>
>
>  On Fri, 11 Mar 2022 12:42:52 -0500 *William Herrin 
> * wrote 
>
> On Fri, Mar 11, 2022 at 9:40 AM Tom Fantacone  wrote:
> > If I run a network and qualify for an /18 right now, can I got to ARIN
> and lease one? I must either buy one on the transfer market
>
> Tom,
>
> I think you misunderstand the transfer market. You don't buy addresses
> on the transfer market. You lease addresses from ARIN and then pay
> someone on the transfer market to release their addresses to ARIN for
> lease to you.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription 
> at:https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:

Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilization for Future Allocations

[Scott Leibrand]

8.5.2 Operational Use reads:

> ARIN allocates or assigns number resources to organizations via transfer 
> solely for the purpose of use on an operational network.


If you’re going to remove that, what is to stop me from opening a new LIR and 
stating that I want pre-qualification for a transfer of a /8 to lease out, 
because I have sales projections that I can lease out a /9 within 24 months, a 
/10 within 12 months, and a /11 within 6 months? And if I fail to meet my sales 
projections, I can sell some or all of the /8 after 12 months (presumably at a 
profit, as prices just keep going up).  

It seems that there should be some limit on initial block size if we’re going 
to rely exclusively on recipients’ leasing projections instead of requiring use 
on an operational network. Once they have leased out 50% of their initial block 
to tenants who are using the space on their own networks, they could then come 
back for approval to receive a larger block via transfer, sized to an 
extrapolation of their 24 month need based on how quickly they leased out their 
existing space. 

Scott

> On Mar 9, 2022, at 8:24 PM, ARIN  wrote:
> 
> 
> The following Draft Policy has been revised and retitled:
>  
> * ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining 
> Utilization for Future Allocations
>  
> Revised text is below and can be found at:
>  
> https://www.arin.net/participate/policy/drafts/2021_6/
>  
> You are encouraged to discuss all Draft Policies on PPML. The AC will 
> evaluate the discussion 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/participate/policy/pdp/
>  
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>  
> Regards,
>  
> Sean Hopkins
> Senior Policy Analyst
> American Registry for Internet Numbers (ARIN)
>  
>  
>  
>  
> Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of 
> Determining Utilization for Future Allocations
>  
> Problem Statement: Current ARIN policy prevents the use of leased-out 
> addresses as evidence of utilization.
>  
> Policy statement:
>  
> Section 1.2 Conservation
>  
> Replace
>  
> “Due to the requirement for uniqueness, Internet number resources of each 
> type are drawn from a common number space. Conservation of these common 
> number spaces requires that Internet number resources be efficiently 
> distributed to those organizations who have a technical need for them in 
> support of operational networks.”
>  
> with
>  
> “Due to the requirement for uniqueness, Internet number resources of each 
> type are drawn from a common number space. Conservation of these common 
> number spaces requires that free-pool (ASN & IPv6) and IPv4 wait-list 
> Internet number resources be efficiently distributed to those organizations 
> who have a technical need for them in support of operational networks.”
>  
> Section 1.4 Stewardship
>  
> Replace
>  
> “The fundamental purpose of Internet number stewardship is to distribute 
> unique number resources to entities building and operating networks thereby 
> facilitating the growth and sustainability of the Internet for the benefit of 
> all.”
>  
> with
>  
> “The fundamental purpose of Internet number stewardship is to distribute 
> unique number resources to facilitate the growth and sustainability of the 
> Internet for the benefit of all.”
>  
> Section 2.4
>  
> Replace
>  
> “2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR 
> that primarily assigns address space to the users of the network services 
> that it provides. LIRs are generally Internet Service Providers (ISPs), whose 
> customers are primarily end users and possibly other ISPs.”
>  
> with
>  
> “2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR 
> that primarily assigns address space to users of the network. LIRs are 
> generally Internet Service Providers (ISPs), whose customers are primarily 
> end users and possibly other ISPs.”
>  
> Section 4.18
>  
> Replace
>  
> “ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 
> 4.10 space) from the ARIN Waitlist.”
>  
> with
>  
> “ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 
> 4.10 space) from the ARIN Waitlist to those with operational need.”
>  
> Delete Section 8.5.2 Operational Use
>  
> Timetable for implementation: Immediate.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> 

Re: [arin-ppml] Draft Policy ARIN-2022-1: MDN Clarification for Qualification

[Scott Leibrand]

+1 to Owen's clarification.

Since it's impossible to evaluate a change like this without seeing what's
being changed, here's the existing language (which should be included in
the Policy statement):

8.5.6. Efficient Utilization of Previous Blocks
Organizations with direct assignments or allocations from ARIN must have
efficiently utilized at least 50% of their cumulative IPv4 address blocks
in order to receive additional space. This includes all space reassigned to
their customers.

8.5.7. Alternative Additional IPv4 Address Block Criteria
In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
address blocks by demonstrating 80% utilization of their currently
allocated space. If they do so, they qualify to receive one or more
transfers up to the total size of their current ARIN IPv4 address holdings,
with a maximum size of /16.

And for reference, the NRPM 4.5 Multiple Discrete Networks policy (for
space from the free pool, which until 2016 was referenced in transfer
policy), states:

7. When applying for additional internet address registrations from ARIN,
the organization must demonstrate utilization greater than 50% of both the
last block allocated and the aggregate sum of all blocks allocated from
ARIN to that organization. If an organization is unable to satisfy this 50%
minimum utilization criteria, the organization may alternatively qualify
for additional internet address registrations by having all unallocated
blocks of addresses smaller than ARIN’s current minimum allocation size.
8. The organization may not allocate additional address space to a location
until each of that location’s address blocks are 80% utilized.

So it appears that this policy change would allow organizations with
individual discrete networks over 80% utilization, but whose overall
utilization is less than 50%, to receive additional space via transfer for
use in the >80% networks. That seems reasonable to me.

-Scott

On Wed, Mar 2, 2022 at 2:27 PM Owen DeLong via ARIN-PPML 
wrote:

> Generally, I don’t have a problem with this, but I think that the
> requirement should be that “Each discrete network requesting additional
> resources (whether via waiting list or transfer) must meet…”
>
> As currently worded, it could be construed to require each discrete
> network to be 80% utilized before a transfer can be acquired by any of
> them, which I think is entirely contrary to the intent of the MDN policy in
> the first place.
>
> Owen
>
>
> Draft Policy ARIN-2022-1: MDN Clarification for Qualification
>
>
> Problem Statement:
>
>
> Problem Statement: The requirements for transfers involving companies
> operating multiple discrete networks under section 8.5 of the NRPM are
> unclear and need clarification.
>
>
> Policy statement:
>
>
> Replace the first paragraph of Section 8.5.7 with the following:
>
> Organizations may qualify for additional IPv4 address blocks by
> demonstrating 80% utilization of their currently allocated space. In
> organizations operating multiple discrete networks, each discrete network
> may be assessed individually for the 80% utilization threshold. To qualify
> under this policy, the organization must provide justification that each
> network is discrete, per the criteria described in section 4.5. Each
> discrete network must meet the projection requirements in section 8.5.5,
> and each discrete network must meet the utilization requirements in section
> 8.5.6. Organizations may receive one or more transfers up to the total size
> of their current ARIN IPv4 address holdings, up to a maximum size of /16.
>
>
> Timetable for implementation: Any
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[Scott Leibrand]

On Wed, Mar 2, 2022 at 2:20 PM Owen DeLong via ARIN-PPML 
wrote:

>
> Replace
>
> “The source entity must be the current rights holder of the IPv4 addresses
> or ASNs recognized by the RIR responsible for the resources, and not be
> involved in any dispute as to the status of those resources.”
>
> with
>
> “The source entity must be the current rights holder of the IPv4 addresses
> or ASN recognized by the RIR responsible for the resources, and not be
> involved in any dispute as to the status of those resources.”
>
>
> I don’t see any difference in this change other than the font size.
>

They're proposing to change ASNs to ASN there.

-Scott
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[Scott Leibrand]

You answered an either-or question with a Y. I’m not on the AC, but if I were 
the shepherd on this proposal I would not be able to incorporate your opinion 
into my assessment of community consensus for or against this policy proposal. 
If you want your opinion to be considered, you might want to express it in 
English. 

Scott

> On Jan 22, 2022, at 12:16 PM, Mattapally Technologies 
>  wrote:
> 
> Y
> 
>> On Saturday, January 22, 2022, Scott Leibrand  
>> wrote:
>> Are you disagreeing with Owen, or objecting to some part of the proposed 
>> changes from 2021-4? If the latter, which change, and why? Despite my 
>> initial concerns, it doesn’t appear that it actually changes policy with 
>> regard to inter-region ASN transfers, which have been allowed for years. 
>> 
>> Scott
>> 
>>>> On Jan 22, 2022, at 3:23 AM, Mattapally Technologies 
>>>>  wrote:
>>>> 
>>> -1
>>> 
>>>> On Friday, January 21, 2022, Owen DeLong via ARIN-PPML 
>>>>  wrote:
>>>> There’s a valid argument to be made that there is no longer any 
>>>> (technical) valid reason to treat 16 and 32-bit ASNs differently… ASNs are 
>>>> ASNs today.
>>>> 
>>>> Owen
>>>> 
>>>> 
>>>>> On Jan 21, 2022, at 09:58 , Fernando Frediani  
>>>>> wrote:
>>>>> 
>>>>> I tend to think that transfers originally exists due to IPv4 exhaustion 
>>>>> and that is justified. IPv6 and 32-bit ASN don't have the same 
>>>>> justification, only 16-bit ASN.
>>>>> 
>>>>> I would also like to understand it better.
>>>>> 
>>>>> Regards
>>>>> Fernando
>>>>> 
>>>>> On 21/01/2022 14:18, Scott Leibrand wrote:
>>>>>> Are Inter-regional transfers of ASNs allowed via policy today? If not, 
>>>>>> this is a substantive change on that topic, and the draft policy should 
>>>>>> be retitled accordingly. 
>>>>>> 
>>>>>> I have no objections to allowing inter-regional ASN transfers, but would 
>>>>>> like to see an explicit argument if we are proposing to change whether 
>>>>>> it is allowed, even if that’s as simple as “some orgs want to do it”.
>>>>>> 
>>>>>> Scott
>>>>>> 
>>>>>>> On Jan 21, 2022, at 7:42 AM, ARIN  wrote:
>>>>>>> 
>>>>>>> Inter-regional transfers of IPv4 number resources and ASNs
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> ARIN-PPML
>>>>>> You are receiving this message because you are subscribed to
>>>>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>> Please contact i...@arin.net if you experience any issues.
>>>>> ___
>>>>> ARIN-PPML
>>>>> You are receiving this message because you are subscribed to
>>>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>>>> Please contact i...@arin.net if you experience any issues.
>>>> 
>>> ___
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[Scott Leibrand]

Are you disagreeing with Owen, or objecting to some part of the proposed 
changes from 2021-4? If the latter, which change, and why? Despite my initial 
concerns, it doesn’t appear that it actually changes policy with regard to 
inter-region ASN transfers, which have been allowed for years. 

Scott

> On Jan 22, 2022, at 3:23 AM, Mattapally Technologies 
>  wrote:
> 
> -1
> 
>> On Friday, January 21, 2022, Owen DeLong via ARIN-PPML  
>> wrote:
>> There’s a valid argument to be made that there is no longer any (technical) 
>> valid reason to treat 16 and 32-bit ASNs differently… ASNs are ASNs today.
>> 
>> Owen
>> 
>> 
>>> On Jan 21, 2022, at 09:58 , Fernando Frediani  wrote:
>>> 
>>> I tend to think that transfers originally exists due to IPv4 exhaustion and 
>>> that is justified. IPv6 and 32-bit ASN don't have the same justification, 
>>> only 16-bit ASN.
>>> 
>>> I would also like to understand it better.
>>> 
>>> Regards
>>> Fernando
>>> 
>>> On 21/01/2022 14:18, Scott Leibrand wrote:
>>>> Are Inter-regional transfers of ASNs allowed via policy today? If not, 
>>>> this is a substantive change on that topic, and the draft policy should be 
>>>> retitled accordingly. 
>>>> 
>>>> I have no objections to allowing inter-regional ASN transfers, but would 
>>>> like to see an explicit argument if we are proposing to change whether it 
>>>> is allowed, even if that’s as simple as “some orgs want to do it”.
>>>> 
>>>> Scott
>>>> 
>>>>> On Jan 21, 2022, at 7:42 AM, ARIN  wrote:
>>>>> 
>>>>> Inter-regional transfers of IPv4 number resources and ASNs
>>>> 
>>>> 
>>>> ___
>>>> ARIN-PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact i...@arin.net if you experience any issues.
>>> ___
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@arin.net if you experience any issues.
>> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[Scott Leibrand]

Thx. Looks like this is indeed solely a clarification then. I support 2021-4. 

Scott

> On Jan 21, 2022, at 9:26 AM, David Farmer  wrote:
> 
> 
> 
> 
>> On Fri, Jan 21, 2022 at 11:18 AM Scott Leibrand  
>> wrote:
>> Are Inter-regional transfers of ASNs allowed via policy today?
> 
> My understanding is, YES they are; See ARIN-2018-1
> 
> https://www.arin.net/vault/policy/proposals/2018_1.html
> 
> Thanks
> 
> -- 
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[Scott Leibrand]

Are Inter-regional transfers of ASNs allowed via policy today? If not, this is 
a substantive change on that topic, and the draft policy should be retitled 
accordingly. 

I have no objections to allowing inter-regional ASN transfers, but would like 
to see an explicit argument if we are proposing to change whether it is 
allowed, even if that’s as simple as “some orgs want to do it”.

Scott

> On Jan 21, 2022, at 7:42 AM, ARIN  wrote:
> 
> Inter-regional transfers of IPv4 number resources and ASNs
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Nomcom rejection explanatory letter

[Scott Leibrand]

This is very disappointing. Under the process to date, it was the
NomCom's prerogative not to provide an explanation. But this
non-explanation makes a mockery of the entire concept of an explanation. It
literally says nothing about why the candidate was not selected. It simply
restates the NomCom's charter and their decision.

If this is the kind of obfuscatory behavior we're going to get out of
requiring explanations under the current process, then that process needs
to be changed more radically than I thought.

-Scott

On Thu, Nov 4, 2021 at 9:37 AM Mike Burns  wrote:

> Hello list,
>
>
> I received the explanation for my exclusion from this year's AC slate.
>
>
> For those who believe this explanation provides any transparency, I post
> it in its totality below to disabuse them of that notion.
>
>
> Required explanations don't move the needle at all in attempting to
> improve the nominations process.
>
>
> Perhaps all it would take would be a simple change to the charging
> language to instruct the nomcom not to exclude candidates who are qualified
> and include those minimum qualifications?
>
>
> Regards,
>
> Mike
>
>
>
>
>
>
> Dear Mr. Burns,
>
> The ARIN Nomination Committee (NomCom) is in receipt of your request for
> an explanatory statement on the reasons why you were not included on the
> Advisory Council candidate slate for the 2021 ARIN Elections. The ARIN
> NomCom reviewed all duly submitted and timely nominations and the materials
> provided by the nominees. The NomCom’s robust deliberation process was
> informed by the diversity of perspectives and experience among NomCom
> Members and strong adherence to the mandate and terms of reference.
>
> Various factors were considered including, but not limited to, experience,
> involvement in the ARIN community, and responses to the nominee
> questionnaires.  After careful and thoughtful review of each nominee, it
> was decided to not put your Advisory Council nomination forward onto the
> initial slate of candidates this year.
>
> Catherine Middleton
> Chair, ARIN Nomination Committee 2021
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2021-7: Make Abuse Contact Useful

[Scott Leibrand]

On Wed, Oct 27, 2021 at 10:27 AM Mike Burns  wrote:

> “I would support the addition of a URL option, without the elimination of
> the Abuse POC at this time.”
>
>
>
> Me too. +1
>

+1

Backwards compatibility is important here. If we want to add URL
capabilities, there's no reason it can't be a new field.

Opposed as written.

-Scott


>
>
> *From:* ARIN-PPML  *On Behalf Of *David
> Farmer via ARIN-PPML
> *Sent:* Wednesday, October 27, 2021 12:51 PM
> *To:* William Herrin 
> *Cc:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2021-7: Make Abuse Contact
> Useful
>
>
>
> And "tel:123-456-7890 <123-456-7890>" is a URL for a phone number.
> However, that means to replace the current POC info you need at least two
> URLs and probably more if you want to support a web form and possibly an
> API option. But I don't believe a single URL is a viable solution.
>
>
>
> But then, with multiple URLs there becomes a question of order of
> preference. Which does the entity providing the URLs prefer and in what
> order? Furthermore, if you provide only a Web Form or API URL, where do you
> call or email if it seems to have gone wrong?
>
>
>
> Simply changing the Abuse Contact to a URL isn't necessarily going to
> make things better, and it could make things much worse. While this could
> allow those that want to be responsive to increase their responsiveness,
> however, I fear that it also allows those that want to be unresponsive to
> obfuscate things even more than is possible today.
>
>
>
> Having staff translate the current POC data to URLs is a reasonable
> transition strategy on the data production side of things. But a flag day
> on the data consumption side, would be unacceptable, at least in my
> opinion. So, there would need to be an overlap where both the Abuse POC and
> Abuse URL Data are available, and I think we are talking about multiple
> years of overlap. Further, for at least for part of that time those that
> want to provide only an Abuse URL would still need to provide an Abuse POC.
>
>
>
> There are many users of the current Abuse POC, and an abrupt change in
> the format of this data is not acceptable in my opinion. So, while I
> support work in this area, some changes are most definitely needed, and
> long-term this seems like the right direction, nevertheless, we need to
> proceed very carefully. Therefore, without at least a more detailed and
> lengthy transition plan, I can not support any proposal that effectively
> eliminates the Abuse POC as we know it today. I would support the addition
> of a URL option, without the elimination of the Abuse POC at this time.
>
>
>
> Thanks.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Oct 27, 2021 at 2:10 AM William Herrin  wrote:
>
> On Tue, Oct 26, 2021 at 2:59 PM John Santos  wrote:
> > My domain has a valid abuse contact (me), and it's been years since I
> actually
> > received anything except spam.  (I check the spam detector output daily
> to make
> > sure it actually is spam, and it always is.  It's usually no more than a
> handful
> > of spam emails daily, probably because I never respond to it or
> originate any
> > email from the "abuse" address, so there is nothing for the spammers to
> harvest.)
> >
> > Under this new scheme, would I still be able to handle abuse the exact
> same way?
>
> Hi John,
>
> "mailto:your@address; is a valid URL, is it not?
>
>
> >> Initial implementation suggested to replace the abuse POC with a URL
> >> pointing to ARIN’s display of the same POC record which was used for
> >> abuse reporting. Should support multiple URLs so that if desired an
> >> organization can specify both “mailto:somebody@here” and
> >> “tel:1234567 <1234567>” if that’s how they actually want abuse
> reported to them.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
>
>
> --
>
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___

Re: [arin-ppml] ARIN Announces the Final Slate of Candidates for the 2021 ARIN Elections

[Scott Leibrand]

The current process for explanations balances privacy and transparency well, if 
and only if the NomCom chooses to provide an explanation: the explanation is 
private unless the candidate chooses to petition or publicly discuss being 
passed over, in which case ARIN does or can post it publicly. 

The missing piece is actually requiring the NomCom to provide an explanation to 
the candidate if asked: right now it’s optional and they rarely do. IMO that is 
the most important change the Board should make to the nominations process. 
(There are some others I’d like to see as well, but they’re less essential.)

Scott

> On Oct 19, 2021, at 5:30 PM, William Herrin  wrote:
> 
> On Tue, Oct 19, 2021 at 1:43 PM Leif Sawyer  wrote:
>> I hear your frustrations for transparency, and I have formulated a 
>> suggestion that I've shared with the NomCom to improve the way that 
>> candidate responses are handled.
> 
> Hi Leif,
> 
> Why not simply ask the rejected candidates if they want an explanation
> in specificity with the understanding that if they answer yes, the
> explanation will be made publicly? That respects both privacy and
> transparency.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Board Election Petition underway

[Scott Leibrand]

The members of the NomCom aren't allowed to make public statements like
that about the private proceedings of the NomCom. Given the NomCom is made
up of individuals that many of us know personally and highly respect, I
think it is unlikely that they acted with any ill intent. And if some
members of the NomCom were attempting to disqualify individuals for
political reasons or anything like that, I suspect at least one member of
the NomCom would have resigned rather than go along with it. More likely,
they were following the process they were asked to perform to the best of
their ability, and that process resulted in qualified candidates being
disqualified on some technicality. The problem is that the process is
entirely black-box, with very little transparency. The best we can hope for
this time around is that the Board investigates what happens and makes some
form of statement after the petition process is complete as to what they
found.

Looking forward, I believe that the process needs to be reformed to be less
completely opaque, and to provide mechanisms for the NomCom to provide
feedback, to the candidates, the board, and the public, as to their reasons
whenever they choose not to place nominated candidates on the ballot.
Several suggestions have already been made on how that could be done, and I
know others are considering other mechanisms. I look forward to seeing the
board candidates' (and existing board members') positions on how they
intend to balance transparency with the need for privacy in reviewing
candidates' backgrounds.

In any event, those solutions must by necessity be applied to future
elections, not to the current situation. The recourse for the current
situation (for ARIN members) is simply to support the petitions and then
vote in the election.

-Scott


On Mon, Oct 11, 2021 at 7:18 PM Michael B. Williams <
michael.willi...@glexia.com> wrote:

> Is NomCom able to explain how this happened? In my opinion, unless they
> cannot offer some credible explanation everyone on NomCom should be removed
> from any position of official power at ARIN. Embarrassing to say the least.
>
> --
>
> *Michael B. Williams *
> Glexia - An IT Company
> Legal Notice:
> The information in this electronic mail message is the sender's
> confidential business and may be legally privileged. It is intended solely
> for the addressee(s). Access to this internet electronic mail message by
> anyone else is unauthorized. If you are not the intended recipient, any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it is prohibited and may be unlawful.
>
>
>
> On Mon, Oct 11, 2021 at 1:35 PM Jason Baugher 
> wrote:
>
>> I signed the petitions to get these 2 candidates on the ballot, because
>> unless someone on the nom-com cares to give us a valid reason to reject
>> them, I feel they belong there.
>>
>>
>>
>> I also answered the survey regarding the prioritization of question,
>> choosing those that address the nom-com and overall behavior and makeup of
>> the board to be the most important.
>>
>>
>>
>> Up until a few years ago, I paid little attention to ARIN governance and
>> policy. What was in place didn’t affect me adversely, so I didn’t read the
>> new policy announcements, didn’t care who was running things, didn’t even
>> bother to vote quite honestly. It wasn’t until the somewhat recent waiting
>> list policy change fiasco that I started making a point of following what
>> is happening with ARIN.
>>
>>
>>
>> With that said, I consider myself somewhat of an outsider, so I may be
>> over-simplifying things. However, this is how I’m interpreting this
>> process.
>>
>> 1: The Board selects a nominating committee, which then has the authority
>> to accept or reject candidates from the ballot.
>>
>> 2: The nominating committee is insulated in as such that they don’t have
>> to provide their reasons for accepting or rejecting the candidate, even to
>> the candidate themselves.
>>
>> 3: The only recourse is for the person to file a petition to get 124
>> member orgs to sign to be forced onto the ballot, which is a hurdle that
>> those already accepted by the nominating committee do not have pass.
>>
>> 4: The end-result would appear to be a limited selection on the ballot of
>> people hand-picked by the existing Board, thereby ensuring the overall
>> direction of the Board stays the same.
>>
>>
>>
>> Someone else already suggested a reform to the system above, where the
>> nom-com would have to provide their reasons for rejection, which I fully
>> support. I’d also suggest that if there is going to be a 2% pe

Re: [arin-ppml] Board Election Petition underway

[Scott Leibrand]

In light of the public and private responses I’ve gotten to this question, it 
seems that the obvious explanations are considered far more credible than any 
innocent ones (of which none have been forthcoming this far).

I would encourage everyone to support these petitions, to solicit candidates’ 
opinions on the matter of candidate selection, and then vote for candidates 
willing to publicly advocate for candidate selection reform at ARIN. Whether or 
not the process is currently undergoing capture, it certainly appears to lack 
the transparency needed to avoid it. 

Scott

> On Oct 9, 2021, at 5:37 PM, Owen DeLong  wrote:
> 
> There were apparently at least 5 candidates. There are 2 open board seats.
> 
> The nom-com approved only 3 candidates, hence my complaint.
> 
> There are 7 open advisory council seats. I did not count the nomination list 
> size, but I assure you it was well short of 14.
> 
> Owen
> 
> 
>> On Oct 9, 2021, at 17:30 , Steven Ryerse  
>> wrote:
>> 
>> If there are enough candidates there ought to be at least 2 for each seat 
>> and more than 2 is also good too. 
>>  
>>  
>> Steven Ryerse
>> President
>>  
>> srye...@eclipse-networks.com | C: 770.656.1460
>> 100 Ashford Center North | Suite 110 | Atlanta, Georgia 30338
>>  
>>   
>>  
>> 
>> 
>>  
>> From: ARIN-PPML  On Behalf Of Mike Burns
>> Sent: Saturday, October 9, 2021 4:45 PM
>> To: Scott Leibrand 
>> Cc: arin-ppml 
>> Subject: Re: [arin-ppml] Board Election Petition underway
>>  
>> I was rejected for an Advisory Council candidacy even though I was a 
>> candidate in the past and am a policy author in multiple registries.
>> Another broker was likewise rejected.
>> There are 7 AC openings, only 10 candidates, but I was rejected.
>> I know another broker who was, like me, solicited to run but then denied a 
>> candidacy.
>> The NomCom is comprised of four insiders, two volunteers, and operates in 
>> the dark.
>> Not saying this is the case, but very few likeminded individuals on the 
>> AC/Board can effectively capture these via NomCom filtering.
>> A dangerous thing for Internet governance in the context of Afrinic. I don't 
>> want the governments of the world taking over from the amateurs.
>> But if we continue to act amateurish...
>>  
>>  
>> Regards,
>> Mike
>>  
>>  
>>  
>>  On Sat, 09 Oct 2021 11:58:00 -0400 Scott Leibrand 
>>  wrote 
>>  
>> Has ARIN disclosed anything about why the NomCom chose to exclude two 
>> obviously-qualified candidates from the ballot when they didn’t yet have 2 
>> candidates per open seat, and the 3 candidates they did include are all less 
>> well-known to the community than both the ones they excluded?
>> 
>> I can hypothesize some possible reasons, but none of them would reflect well 
>> on the NomCom, so I am reluctant to do so without learning their stated 
>> reason(s). 
>> 
>> Scott
>> 
>> > On Oct 9, 2021, at 7:39 AM, Bill Woodcock  wrote:
>> > 
>> > 
>> >> On Oct 9, 2021, at 4:03 PM, Martin Hannigan  wrote:
>> >> There's a petition for two people to be added to the Trustee ballot after 
>> >> being rejected by the nom com.
>> > 
>> > Yes! Go vote on the petitions, so you’ll have more than three choices to 
>> > fill the two open board seats, when the election comes. Give yourself more 
>> > options.
>> > 
>> > -Bill
>> > 
>> > ___
>> > ARIN-PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> > Unsubscribe or manage your mailing list subscription at:
>> > https://lists.arin.net/mailman/listinfo/arin-ppml
>> > Please contact i...@arin.net if you experience any issues.
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>  
>> 
>> 
>> 
>> CAUTION: This email originated from outside the organization. Do not click 
>> links or open attachments unless you recognize the sender and know the 
>> content is safe. 
>> 
>>  
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
> 
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Board Election Petition underway

[Scott Leibrand]

Has ARIN disclosed anything about why the NomCom chose to exclude two 
obviously-qualified candidates from the ballot when they didn’t yet have 2 
candidates per open seat, and the 3 candidates they did include are all less 
well-known to the community than both the ones they excluded?

I can hypothesize some possible reasons, but none of them would reflect well on 
the NomCom, so I am reluctant to do so without learning their stated reason(s). 

Scott

> On Oct 9, 2021, at 7:39 AM, Bill Woodcock  wrote:
> 
> 
>> On Oct 9, 2021, at 4:03 PM, Martin Hannigan  wrote:
>> There's a petition for two people to be added to the Trustee ballot after 
>> being rejected by the nom com.
> 
> Yes!  Go vote on the petitions, so you’ll have more than three choices to 
> fill the two open board seats, when the election comes.  Give yourself more 
> options.
> 
>-Bill
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[Scott Leibrand]

Gotcha, thx. I interpret the existing text the same as the new text (based
on the original intent when it was written), and presume ARIN has been
doing the same, but I could see how other interpretations could've been
valid.

I support the policy as written.

-Scott

On Tue, Aug 24, 2021 at 9:51 AM William Herrin  wrote:

> On Tue, Aug 24, 2021 at 9:23 AM Scott Leibrand 
> wrote:
> > I support these changes, but would like to hear from anyone who thinks
> they would change (vs. just clarify) anything.
>
> Hi Scott,
>
> In the original text, it's unclear whether the AS numbers are intended
> to be independently transferrable. In the new text, it's clear that
> they are. That's a material change, not just cleaning up a difficult
> word construction.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[Scott Leibrand]

+1

I support these changes, but would like to hear from anyone who thinks they 
would change (vs. just clarify) anything. 

Scott

> On Aug 24, 2021, at 8:43 AM, Owen DeLong via ARIN-PPML  
> wrote:
> 
> I don’t understand how these are non-editorial in nature other than possibly 
> the one to 8.5.6 which technically narrows the scope to no longer 
> accidentally (and absurdly) include IPv6 space reassigned to customers in an 
> IPv4 calculation.
> 
> As such, I support the changes (they add clarity and don’t actually change 
> policy), but I would also have considered them editorial in nature as they 
> are corrections to errata and/or clarification of existing policy practice.
> 
> Owen
> 
> 
>> On Aug 24, 2021, at 05:52 , ARIN  wrote:
>> 
>> On 19 August 2021, the ARIN Advisory Council (AC) accepted "ARIN-prop-299: 
>> Clarifications to Sections 8.3, 8.4 and 8.5.6" as a Draft Policy.
>>  
>> Draft Policy ARIN-2021-4 is below and can be found at:
>>  
>> https://www.arin.net/participate/policy/drafts/2021_4/
>>  
>> 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/participate/policy/pdp/
>>  
>> Draft Policies and Proposals under discussion can be found at: 
>> https://www.arin.net/participate/policy/drafts/
>>  
>> Regards,
>>  
>> Sean Hopkins
>> Senior Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>  
>>  
>>  
>>  
>> Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6  
>>  
>> Problem Statement:
>>  
>> The current language in Sections 8.3 and 8.4 is not clear regarding ASN-only 
>> transactions as well as the term “number resources”. The current language in 
>> Section 8.5.7 is not clear with regard to additional IPv4 space.
>>  
>> Policy statement:
>>  
>> In Section 8.3:
>>  
>> Replace
>>  
>> “In addition to transfers under section 8.2, IPv4 numbers resources and ASNs 
>> may be transferred according to the following conditions.”
>>  
>> with
>>  
>> “In addition to transfers under section 8.2, IPv4 address and/or ASN 
>> resources may be transferred according to the following conditions.”
>>  
>> Replace
>>  
>> “The source entity must be the current registered holder of the IPv4 address 
>> resources, and not be involved in any dispute as to the status of those 
>> resources.”
>>  
>> with
>>  
>> “The source entity must be the current registered holder of the IPv4 address 
>> and/or ASN resources, and not be involved in any dispute as to the status of 
>> those resources.”
>>  
>> In Section 8.4:
>>  
>> Replace
>>  
>> “Inter-regional transfers of IPv4 number resources and ASNs may take place 
>> only via RIRs who agree to the transfer and share reciprocal, compatible 
>> needs-based policies.”
>>  
>> with
>>  
>> “Inter-regional transfers of IPv4 addresses and/or ASN resources may take 
>> place only via RIRs who agree to the transfer and share reciprocal, 
>> compatible needs-based policies.”
>>  
>> Replace
>>  
>> “The source entity must be the current rights holder of the IPv4 address 
>> resources recognized by the RIR responsible for the resources, and not be 
>> involved in any dispute as to the status of those resources.”
>>  
>> with
>>  
>> “The source entity must be the current rights holder of the IPv4 address 
>> and/or ASN resources recognized by the RIR responsible for the resources, 
>> and not be involved in any dispute as to the status of those resources.”
>>  
>> In Section 8.5.6:
>>  
>> Replace
>>  
>> “Organizations with direct assignments or allocations from ARIN must have 
>> efficiently utilized at least 50% of their cumulative IPv4 address blocks in 
>> order to receive additional space. This includes all space reassigned to 
>> their customers.”
>>  
>> with
>>  
>> “Organizations with direct assignments or allocations from ARIN must have 
>> efficiently utilized at least 50% of their cumulative IPv4 address blocks in 
>> order to receive additional IPv4 space. This includes all IPv4 space 
>> reassigned to their customers.”
>>  
>> Comments:
>>  
>> These changes were originally included in ARIN-edit-2021-1. Staff and Legal 
>> review of ARIN-edit-2021-1 on June 14, 2021 indicated that some changes were 
>> not editorial in nature. The editorial changes went forward in 
>> ARIN-edit-2021-1 and the non-editorial changes are included here.
>>  
>> Timetable for implementation: Immediate
>>  
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> 

Re: [arin-ppml] Revised - Editorial Change ARIN-edit-2020-9: Section 8 Editorial Clean-up

[Scott Leibrand]

I assume this replaces the previous editorial change proposal that I had
questions about? If so, this new one looks good to me.

-Scott

On Tue, Jul 27, 2021 at 9:56 AM ARIN  wrote:

> The following Editorial Change has been Revised:
>
>
>
> * ARIN-edit-2020-9: Section 8 Editorial Clean-up
>
>
>
> Revised text is below and can be found at:
>
>
>
> https://www.arin.net/participate/policy/drafts/ARIN_edit_2020_9/
>
>
>
> The process for Editorial Changes is found in Part One, Section 3.1,
> paragraph 3 of the Policy Development Process (PDP):
>
>
>
> "Changes to policy that are purely editorial and non-substantial in nature
> are outside the scope of the full Policy Development Process and may only
> be made with 30 days public notice followed by the concurrence of both the
> ARIN Advisory Council and ARIN Board of Trustees that the changes are
> non-substantial in nature."
>
>
>
> Your feedback on this Editorial Change is encouraged. This review period
> will close on 26 August 2021.
>
>
>
> The PDP can be found at:
>
>
>
> https://www.arin.net/participate/policy/pdp/
>
>
>
> Draft Policies and Proposals under discussion can be found at:
>
>
>
> https://www.arin.net/participate/policy/drafts/
>
>
>
> Regards,
>
>
>
> Sean Hopkins
>
> Senior Policy Analyst
>
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
>
> Editorial Change ARIN-edit-2020-9: Section 8 Editorial Clean-up
>
>
>
> Problem Statement:
>
>
>
> ARIN staff have identified some areas of potential NRPM editorial
> clean-up. Building on those recommendations the ARIN AC NRPM Clean-up
> Working Group undertook an editorial review of the NRPM.
>
>
>
> The focus of the review was to clarify and simplify language, employ
> consistent and more up to date terminology throughout and renumber the
> sections after removing section numbers that were no longer being utilized.
> The changes resulting from this review were captured in ARIN-edit-2020-9,
> proposed in September 2020.
>
>
>
> The portions of ARIN-edit-2020-9 relating to Sections 8.3 and 8.4 of the
> NRPM are presented in this editorial change for community consideration.
> The remaining portions will be presented separately.
>
>
>
> Policy Statement:
>
>
>
> In Section 8.3.:
>
>
>
> Under “Conditions on source of the transfer,” replace “Number resources
> received as the result of an 8.2 transfer are out of scope for the purposes
> of this restriction” with “This restriction does not include 8.2 transfers.”
>
>
>
> In Section 8.4.:
>
>
>
> Under “Conditions on source of the transfer,” replace “Number resources
> received as the result of an 8.2 transfer are out of scope for the purposes
> of this restriction” with “This restriction does not include 8.2 transfers.”
>
>
>
> Timetable for Implementation: Immediate
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Editorial Change ARIN-edit-2020-9: Section 8 Editorial Clean-up

[Scott Leibrand]

Can you explicitly explain why removing the waitlist
references/restrictions is considered editorial, so we don’t have to guess?

-Scott




--
On Wed, Jul 21, 2021 at 6:18 AM, ARIN  wrote:

The following Editorial Change has been Revised:

* ARIN-edit-2020-9: Section 8 Editorial Clean-up



Revised text is below and can be found at:



https://www.arin.net/participate/policy/drafts/ARIN_edit_2020_9/



The process for Editorial Changes is found in Part One, Section 3.1,
paragraph 3 of the Policy Development Process (PDP):



"Changes to policy that are purely editorial and non-substantial in nature
are outside the scope of the full Policy Development Process and may only
be made with 30 days public notice followed by the concurrence of both the
ARIN Advisory Council and ARIN Board of Trustees that the changes are
non-substantial in nature."



Your feedback on this Editorial Change is encouraged. This review period
will close on 20 August 2021.



The PDP can be found at:

https://www.arin.net/participate/policy/pdp/



Draft Policies and Proposals under discussion can be found at:

https://www.arin.net/participate/policy/drafts/



Regards,



Sean Hopkins

Senior Policy Analyst

American Registry for Internet Numbers (ARIN)



Editorial Change ARIN-edit-2020-9: Section 8 Editorial Clean-up



Problem Statement:



ARIN staff have identified some areas of potential NRPM editorial clean-up.
Building on those recommendations the ARIN AC NRPM Clean-up Working Group
undertook an editorial review of the NRPM.



The focus of the review was to clarify and simplify language, employ
consistent and more up to date terminology throughout and renumber the
sections after removing section numbers that were no longer being utilized.
The changes resulting from this review were captured in ARIN-edit-2020-9,
proposed in September 2020. 2019-1 also had waitlist restriction language
put into 8.4.



The portions of ARIN-edit-2020-9 relating to Sections 8.3 and 8.4 of the
NRPM are presented in this editorial change for community consideration.
The remaining portions will be presented separately.



Policy statement:



In Section 8.3.:



Under "Conditions on source of the transfer," replace "Number resources
received as the result of an 8.2 transfer are out of scope for the purposes
of this restriction" with "This restriction does not include 8.2
transfers."



Under "Conditions on source of the transfer," remove "The source entity
will not be allowed to apply for IPv4 address space under Section 4.1.8.
ARIN Waitlist for a period of 36 months following the transfer of IPv4
address resources to another party."



Under "Conditions on recipient of the transfer," remove "If applicable the
recipient will be removed from the ARIN Waitlist and will not be allowed to
reapply under section 4.1.8. ARIN Waitlist for a period of 90 days."



In Section 8.4.:



Under "Conditions on source of the transfer," replace "Number resources
received as the result of an 8.2 transfer are out of scope for the purposes
of this restriction" with "This restriction does not include 8.2
transfers."



Comments:



Timetable for implementation: Immediate.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2021-3: Private AS Number and Unique Routing Policy Clarifications

[Scott Leibrand]

On Tue, Jul 20, 2021 at 12:52 PM ARIN  wrote:

> On 15 July 2021, the ARIN Advisory Council (AC) accepted "ARIN-prop-298:
> Private AS Number and Unique Routing Policy Clarifications" as a Draft
> Policy.
>
>
>
> 
>
> Draft Policy ARIN-2021-3: Private AS Number and Unique Routing Policy
> Clarifications
>
>
>
> Problem Statement:
>
>
>
> At ARIN 47, staff identified three points of potential confusion with
> current text in NRPM Section 5: AS Numbers.
>
>
>
> 1. “Sites that do not require a unique AS Number should use one or more of
> the AS Numbers reserved for private use.” Some customers are not aware that
> their need for a unique AS Number depends upon their need (or lack thereof)
> to utilize the AS Number on the public Internet.
>
>
>
> 2. “In order to be assigned an AS Number, each requesting organization
> must provide ARIN with verification that it has one of the following…A
> unique routing policy (its policy differs from its border gateway peers)…A
> multihomed site.” Few customers qualify for an AS Number under the “unique
> routing policy” requirement, specifically because they aren’t aware of what
> “unique routing policy” applies to.
>
>
>
> 3. “AS Numbers are issued based on current need. An organization should
> request an AS Number only when it is already multihomed or will immediately
> become multihomed.” All ARIN delegations are based on current needs, and
> some customers aren’t aware they need network plans when they request an AS
> Number. Additionally, clarification that some organizations may have a
> unique need for an AS Number outside of utilizing a unique routing policy,
> such as BGP.
>
>
>
> Policy statement:
>
>
>
> In Section 5 -
>
>
>
> Replace
>
>
>
> “Sites that do not require a unique AS Number should use one or more of
> the AS Numbers reserved for private use.”
>
>
>
> with
>
>
>
> “Private ASNs should be used only when there is no plan to use them on the
> public Internet.”
>

I am not necessarily opposed to this change, but am not clear on what the
rationale is for it, and therefore on whether or not its effects match our
intent. The existing text requires that everyone who doesn't need a unique
ASN (for use on the public Internet) use a private ASN. The new text
recommends that private ASNs *only* be used by networks who aren't using
them on the public Internet. The new text does not require or even
recommend that sites running BGP internally use a private ASN, as the
original text did: it just recommends against the reverse.

One practical effect of this change would be that ARIN would be going on
record against multihomed organizations using a private ASN, peering with
an upstream, and having the upstream strip the private ASN from their
announcements so that they're originated from the upstream's ASN. Maybe
that would be a good change, now that 4-byte ASNs are widely usable and
there's no shortage. But if so, we need to revise the problem statement to
actually make that argument. Right now, it just states that "some customers
are not aware" of the meaning of the current policy, and then inverts the
policy without any further rationale for doing so.


>
> Replace
>
>
>
> “1. A unique routing policy (its policy differs from its border gateway
> peers) 2. A multihomed site.”
>
>
>
> with
>
>
>
> “1. A plan to connect their network using a unique routing policy, such as
> Border Gateway Protocol (BGP) 2. A network requiring routing policies to be
> deployed which are unique only to that network”
>

Another way to address the issue Chris raised here would be to just add the
word "with" before Border Gateway Protocol, so it reads "... using a unique
routing policy, such as with Border Gateway Protocol (BGP) ..."


>
> Replace
>
>
>
> “AS Numbers are issued based on current need. An organization should
> request an AS Number only when it is already multihomed or will immediately
> become multihomed.”
>
>
>
> with
>
>
>
> “AS Numbers should be requested when an organization has network plans
> ready and is either planning to use a unique routing policy (such as BGP)
> or has a unique need for an AS Number.”
>

Adding "with", so it reads "(such as with BGP)" would also be a good
clarification here.

-Scott
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Last Call - Recommended Draft Policy ARIN-2020-7: 4.4 gTLD Micro-allocation Clarification

[Scott Leibrand]

IMO this is editorial, but either way I support the clarification.

-Scott




--
On Tue, Apr 20, 2021 at 11:43 AM, ARIN  wrote:

On 15 April 2021, the ARIN Advisory Council (AC) sent the following
Recommended Draft Policy to Last Call:



* ARIN-2020-7: 4.4 gTLD Micro-allocation Clarification



Feedback is encouraged during the Last Call period. All comments should be
provided to the Public Policy Mailing List. Last Call will expire on 4 May
2021.



The Recommended Draft Policy text is below and available at:

https://www.arin.net/participate/policy/drafts/2020_7/



The ARIN Policy Development Process is available at:

https://www.arin.net/participate/policy/pdp/



Regards,



Sean Hopkins

Senior Policy Analyst

American Registry for Internet Numbers (ARIN)







Recommended Draft Policy ARIN-2020-7: 4.4 gTLD Micro-allocation
Clarification



AC Assessment of Conformance with the Principles of Internet Number
Resource Policy:



The draft Policy ARIN-2020-7 is fair, impartial ,technically sound and
supported by the community. This draft policy removes “new” from “new GTLD”
in NRPM Section 4.4 in an effort to reduce confusion for those who may view
the policy itself as “new” when it is from 2012.



Problem Statement:



As stated in NRPM section 4.4: Micro-allocation



ICANN-sanctioned gTLD operators may justify up to the equivalent of an IPv4
/23 block for each authorized new gTLD, allocated from the free pool or
received via transfer, but not from the above reservation.



The term “new gTLD” is confusing and refers to all gTLD’s that have been
created since June of 2012.



Policy statement:



ICANN-sanctioned gTLD operators may justify up to the equivalent of an IPv4
/23 block for each authorized gTLD, allocated from the free pool or
received via transfer, but not from the above reservation.



Comments:



This proposal stems from a suggestion in the January, 2019 Policy
Experience Report.



Timetable for Implementation: Immediate
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-2: Reinstatement of Organizations Removed from Waitlist by Implementation of ARIN-2019-16

[Scott Leibrand]

I oppose any special treatment being given to organizations that encourage
their customers to spam the policy list with messages in support of such
special treatment.

-Scott

On Wed, Oct 21, 2020 at 4:16 PM Chad Geiser via ARIN-PPML <
arin-ppml@arin.net> wrote:

> To Whom it May Concern,
>
>
>
> We do business with Stratus as a Fiber provider for our operation as well
> as many of our clients. They are a legitimate internet service provider. We
> support the Stratus stance on this policy. Thank you for the consideration.
>
>
>
> Sincerely,
>
> Chad Geiser
> Chad​
>  Geiser
> Director of Strategic Partnerships
> O: *309-662-7723* <309-662-7723>  |  D: *309-664-8146*  |  M:
> *309-824-6463* <309-824-6463>
> E: *cgei...@integrityts.com*   |  W:
> *integrityts.com* 
> 816 S. Eldorado Road, Suite 4
> ​Bloomington, IL 61704
> [image: Facebook] 
> [image: Instgram] 
> [image: LinkedIn]
> 
> [image: Twitter] 
>
> This message contains confidential information and is intended only for
> the intended recipients. If you are not an intended recipient you should
> not disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
> The sender therefore does not accept liability for any errors or omissions
> in the contents of this message, which arise as a result of e-mail
> transmission. If verification is required please request a hard-copy
> version. v03232016
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

"Summarily" seems punitive, and doesn't seem necessary in this context.
Perhaps just remove it and just leave "will be removed from the waitlist"?
Or replace it with something like "immediately".

-Scott

On Thu, May 14, 2020 at 8:50 AM Owen DeLong  wrote:

> I support this addition and support the policy with the addition.
>
> Owen
>
>
> On May 14, 2020, at 08:37, Fernando Frediani  wrote:
>
> 
>
> I support this proposal.
> It's fair to everybody and helps avoid fraud.
>
> Regards
> Fernando
> On 14/05/2020 11:56, Kat Hunter wrote:
>
> After making adjustments to the text, ARIN staff and legal conducted a new
> staff and legal review on 2019-1. You can view the updated review here:
> https://www.arin.net/participate/policy/drafts/2019_1/#staff-and-legal-review-30-april-2020
>  .
> It has been suggested that
> "It is worth noting that this Draft Policy does not include the removal
> of pending ARIN Waitlist requests for organizations that act as source
> organizations for 8.2, 8.3, or 8.4 transfers, which would allow them to
> conduct such transfers while waitlisted, and receive resources from the
> ARIN Waitlist immediately thereafter, as all organizations on the ARIN
> Waitlist have already applied, and are pending fulfillment.
>
> The text is clear and understandable, and can be implemented as written."
>
> After some discussion with some members of the AC, it was suggested that a
> new subsection is added to section 8 which would allow for additional
> clarity from this policy and some future cleanup via other future policy.
>
> "8.6 Waitlist Restrictions
>
> Any organization which is on the wait list and submits a request to be the
> source of a transfer under any provision in section 8 will be summarily
> removed from the wait list."
>
> I'd like to get the community's thoughts on the addition. With this
> addition, would you support the policy as written?
>
> -Kat Hunter
>
> On Tue, Mar 24, 2020 at 1:24 PM Kat Hunter  wrote:
>
>> Owen, I think this is a good suggestion. I've updated the month
>> designations in the other section to 90 days as, I agree, it is more
>> precise when we are discussing shorter amounts of time. Additionally, I've
>> taken your suggestion on wordsmithing that section and adjusted it just a
>> little.
>>
>> " An organization which serves as the source of an 8.2 IPv4 transfer will
>> not be allowed to apply for IPv4 address space under section 4.1.8 ARIN
>> Waitlist for a period of 36 months following said transfer unless the
>> recipient organization remains a subsidiary, parent company, or under
>> common ownership with the source organization.".
>>
>> I wanted to make sure I specified that this was in reference to IPv4 and
>> that the organization also remains a subsidiary, parent company, or under
>> common ownership.  Thank you for the input. Additionally I'd like to see if
>> there is anyone else that still supports or no longer longer supports this
>> policy as written.
>>
>> Kat Hunter
>>
>> On Wed, Mar 11, 2020 at 4:42 AM Owen DeLong  wrote:
>>
>>>
>>>
>>> > On Mar 9, 2020, at 06:26 , ARIN  wrote:
>>> >
>>> > On 20 February 2020, the ARIN Advisory Council (AC) reverted the
>>> following Recommended Draft Policy to Draft Policy Status due to community
>>> feedback recommending significant substantive changes.:
>>> >
>>> > * Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
>>> >
>>> > The text has since been revised in response to that feedback.
>>> >
>>> > Revised text is below and can be found at:
>>> >
>>> > https://www.arin.net/participate/policy/drafts/2019_1/
>>> >
>>> > 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/participate/policy/pdp/
>>> >
>>> > Draft Policies and Proposals under discussion can be found at:
>>> > https://www.arin.net/participate/policy/drafts/
>>> >
>>> > Regards,
>>> >
>>> > Sean Hopkins
>>> > Policy Analyst
>>> > American Registry for Internet Numbers (ARIN)
>>> >
>>> >
>>> >
>>> >
>>> > Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
>>> >
>>> > Problem Statement:
>>> >
>>> > Per a recent ARIN Policy Experience Report and resulting AC
>>> discussion, it was noted that the language of Section 4.1.8 is imprecise in
>>> that it can be interpreted as specifying a waiting period for any
>>> allocation activity, as opposed to being intended to limit only the
>>> frequency of IPv4 allocations under Section 4.
>>> >
>>> > The same Policy Experience Report also noted that ARIN staff has
>>> observed a pattern where an organization transfers space 

Re: [arin-ppml] ARIN-2019-19 Require IPv6 before receiving Section 8 IPv4 Transfers

[Scott Leibrand]

Please knock it off with the unfounded allegations of drug use before we need 
to get the AUP committee involved. 

And more broadly, I don’t think it’s helpful to argue about the motivations of 
IPv6 proponents or whether v6 adoption is continuing or not. The relevant 
question at hand is whether anyone has proposed an enforceable ARIN policy 
whose benefits exceed its costs. To date no one has proposed such a policy to 
further encourage IPv6 adoption, so IMO this discussion will not be useful 
until/unless someone comes up with a new idea that doesn’t gave all the 
enforceability and ineffectiveness problems of those proposed so far.  

Scott

> On Jan 20, 2020, at 8:19 AM, Michel Py  
> wrote:
> 
> 
>> 
>> Andrew Kirch wrote :
>> I post here very rarely to not at all but your assertion that "IPv6 
>> is leveling off" ranges somewhere between insane and drug-addled.  
>> https://www.google.com/intl/en/ipv6/statistics.html 
> 
> Zoom the graph between July 2019 and today and tell us which drug it is you 
> are taking that shows you any growth for the last 6 or 7 months. Must be the 
> good stuff. Shrooms ?
> 
> Michel.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-2019-19 Require IPv6 before receiving Section 8 IPv4 Transfers

[Scott Leibrand]

On Mon, Jan 13, 2020 at 9:06 AM Andrew Dul  wrote:

> Happy New Year everyone...
>
> We had a robust discussion on this list before the New Year, but it was
> clear that we don't have consensus on the current draft.  Thus to help move
> this draft forward...  I'm proposing a couple of questions to see if we can
> find middle ground here to update the text of the draft policy.
>
> The policy as written today would require organizations who wish to obtain
> an IPv4 transfer to complete a limited scope IPv6 deployment.
>
> Do you support any IPv6 requirements on an IPv4 transfer?
>

Most definitely not.

Would you support IPv6 requirements for receiving a block via the ARIN
> wait-list?
>
> Do you support different IPv6 deployment criteria that would qualify an
> organization for a IPv4 transfer?  (Such as, just requiring the org to have
> an IPv6 allocation or assignment from ARIN)  Please propose different IPv6
> criteria that you would support if the current criteria is unacceptable.
>

I'm not categorically opposed to IPv6 requirements tied to waitlist
allocations, but I'm skeptical that there is any set of requirements that
ARIN could impose that would be fully enforceable, meaningful in enough
cases to drive adoption, and not onerous.

Requiring an IPv6 allocation/assignment, or even requiring someone to route
an IPv6 block, wouldn't drive adoption enough to be meaningful.

-Scott

>
> Thanks for your comments on this draft,
>
> Andrew
>
>
> ===
>
> *Current Policy Statement:*
>
> In section 8.5.2, add the following language to the end of the paragraph
> entitled “Operational Use”:
>
> Such operational network must at minimum include an allocation or
> assignment by ARIN of IPv6 address space under the same Org ID receiving
> the transferred IPv4 space. Such Org must be able to prove this IPv6 space
> is being routed by using it to communicate with ARIN.
>
> In the event the receiver provides a written statement from its upstream
> that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.
>
> ===
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-21: Reserved Pool Replenishment

[Scott Leibrand]

Support. In the last sentence I would remove the words “which is” for clarity.

Scott

> On Dec 24, 2019, at 4:42 AM, ARIN  wrote:
> 
> 
> On 19 December 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-281: 
> Reserved Pool Replenishment" as a Draft Policy.
> 
> Draft Policy ARIN-2019-21 is below and can be found at:
> 
> https://www.arin.net/participate/policy/drafts/2019_21/
> 
> 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/participate/policy/pdp/
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> Draft Policy ARIN-2019-21: Reserved Pool Replenishment
> 
> Problem Statement:
> 
> While the current level of resources in the reserve pools created in Sections 
> 4.4 and 4.10 presently seem more than adequate for their intended purposes. 
> Nevertheless, even these well-resourced pools will eventually run out. 
> Therefore, we should make arrangements for their replenishment, if or when 
> necessary.
> 
> Policy Statement:
> 
> Add a new subsection in IPv4 General Principles, Section 4.1;
> 
> 4.1.X Reserved Pool Replenishment
> 
> Any resources allocated from a reserved pool created in Sections 4.4 or 4.10, 
> or any other reserved pools created in the future, that are returned, 
> reclaimed, or revoked will be returned to the reserved pool they were 
> originally allocated from, regardless of the current level of each pool. 
> Further, any other resources returned, reclaimed, or revoked will be 
> prioritized for the replenishment of any reserved pool that falls below a 
> running three-year supply, which is based on the previous three years of 
> allocations from each pool.
> 
> Timetable for Implementation: Immediate
> 
> Anything Else:
> 
> ARIN Staff should regularly report on the levels and projected run-times for 
> each reserved pool and immediately report when any reserved pool falls below 
> a three-year running supply.
> 
> A three-year running supply was chosen to provide the ARIN Policy Community 
> adequate time to react through policy, as deemed appropriate at that time, to 
> an imminent run out event for one of the reserved pools.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-20: Harmonization of Maximum Allocation Requirements under Sections 4.1.8 (ARIN Waitlist) and 4.2.2 (Initial Allocation to ISPs)

[Scott Leibrand]

Support. This should be a no-op for actual allocations, but improves clarity 
and consistency. 

Scott

> On Dec 24, 2019, at 4:38 AM, ARIN  wrote:
> 
> 
> On 19 December 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-279: 
> Harmonization of Maximum Allocation Requirements under Sections 4.1.8 (ARIN 
> Waitlist) and 4.2.2 (Initial Allocation to ISPs)" as a Draft Policy.
> 
> Draft Policy ARIN-2019-20 is below and can be found at:
> 
> https://www.arin.net/participate/policy/drafts/2019_20/
> 
> 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/participate/policy/pdp/
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Draft Policy ARIN-2019-20: Harmonization of Maximum Allocation Requirements 
> under Sections 4.1.8 (ARIN Waitlist) and 4.2.2 (Initial Allocation to ISPs)
> 
> Problem Statement:
> 
> Under the current ARIN waitlist policy (section 4.1.8), ARIN now only issues 
> IPv4 assignments/allocations (excluding section 4.4 and 4.10 space) from the 
> ARIN waitlist. The maximum size aggregate for which an organization may 
> qualify at any one time is a /22. On the other hand, the current initial 
> allocations to ISPs policy (section 4.2.2) provides that direct assignments 
> or allocations from ARIN qualify for an initial allocation of up to a /21, 
> subject to ARIN’s minimum allocation size. This proposal seeks to resolve the 
> conflict in the maximum allocation size requirements between the two sections 
> in favour of the requirement in the waitlist policy, since that is the one 
> that is intended to govern at the present time. Reconciling the policy 
> language as proposed herein will avoid confusion by readers of the NRPM.
> 
> Policy statement:
> 
> Change the first sentence of section 4.2.2 to read:
> 
> “All ISP organizations without direct assignments or allocations from ARIN 
> qualify for an initial allocation of up to a /22, subject to ARIN’s minimum 
> allocation size.”
> 
> Timetable for Implementation: Immediate
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

Does this open up the possibility that an organization performs its 8.2
transfer to a wholly-owned subsidiary, and then sells that subsidiary to a
third party, to bypass the limitation on applying for more IPv4 space?  Do
we need to change "was a subsidiary" to "was, and remains, a subsidiary" or
similar?

-Scott

On Fri, Dec 13, 2019 at 8:34 AM Kat Hunter  wrote:

> Happy Friday Everyone;
> Draft Policy ARIN-2019-1 is below and can be found at:
> https://www.arin.net/participate/policy/drafts/2019_1/
>
> During the Austin meeting there was concern for some of the wording of
> 2019-1. It was suggested that the word "Repeated" was too vague and that
> companies that performed M transfer that was a subsidiary, parent
> company, or an organization under common ownership of the same parent
> company as the applicant organization should not be removed or kept from
> the waitlist because of a consolidation of resources. We've updated the
> wording on 2019-1 and would appreciate discussion on the updates. Thanks so
> much in advance.
> ---
> Problem Statement:
>
> Per a recent ARIN Policy Experience Report and resulting AC discussion, it
> was noted that the language of Section 4.1.8 is imprecise in that it can be
> interpreted as specifying a waiting period for any allocation activity, as
> opposed to being intended to limit only the frequency of IPv4 allocations
> under Section 4.
>
> The same Policy Experience Report also noted that ARIN staff has observed
> a pattern where an organization transfers space under NRPM Section 8.2 to a
> specified recipient, and then immediately applies for space under Section
> 4. This activity appears to be speculative in nature and not consistent
> with sound address management policy.
>
> The updated language in this proposal addresses the two issues above, as
> both concerns can be addressed via modifications to the same section and
> sentence thereof of the NRPM:
>
> Clarifies the waiting period to only prohibit requests for IPv4
> allocations under Section 4 of the NRPM
> Disallows organizations that have transferred space to other parties
> within the past 36 months from applying for additional IPv4 space under
> NRPM Section 4.
> Policy Statement:
>
> Current language found in NRPM Section 4.1.8 - Unmet Requests:
>
> Repeated requests, in a manner that would circumvent 4.1.6, are not
> allowed: an organization currently on the waitlist must wait 90 days after
> receiving a distribution from the waitlist before applying for additional
> space. ARIN, at its sole discretion, may waive this requirement if the
> requester can document a change in circumstances since their last request
> that could not have been reasonably foreseen at the time of the original
> request, and which now justifies additional space. Qualified requesters
> will also be advised of the availability of the transfer mechanism in
> section 8.3 as an alternative mechanism to obtain IPv4 addresses.
>
> Proposed new language:
>
> Multiple requests are not allowed: an organization may not apply for IPv4
> address resources under this section if they have received an allocation,
> assignment, or transfer of IPv4 resources through a specified transfer
> under sections 8.3 or 8.4 or waitlist allocation less than three months
> prior, or if the organization has transferred IPv4 address resources to
> another party under Section 8 less than 36 months prior to its application
> under this section. However, an organization may apply for IPv4 address
> resources under this section if they have transferred IPv4 address
> resources under section 8.2 during the previous 36 months if the recipient
> organization was a subsidiary, parent company, or an organization under
> common ownership of the same parent company as the applicant organization.
> ARIN may at its sole discretion, waive this restriction if the requester
> can document a change in circumstances since their last request that could
> not have been reasonably foreseen at the time of the original request, and
> which now justifies additional space. Qualified requesters will also be
> advised of the availability of the transfer mechanism in section 8.3 as an
> alternative mechanism to obtain IPv4 addresses.
>
> -Kat Hunter
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-19: Require IPv6 Before Receiving Section 8 IPv4 Transfers

[Scott Leibrand]

Agreed. If you want a meaningful use requirement, legislate a meaningful use 
requirement. Tie it to free money, as with EHRs and FHIR, or figure out some 
legislative authority to mandate it. ARIN isn’t a legislative authority: 
they’re a registry, whose job it is to keep track of who’s using what numbers. 

Scott

> On Nov 11, 2019, at 4:56 PM, Alan Batie  wrote:
> 
> On 11/11/19 4:51 PM, hostmas...@uneedus.com wrote:
>> Then I guess we need to make the IPv6 connectivity an ongoing obligation
>> to keep the additional IPv4 blocks, rather than a one shot test during
>> transfer to eliminate the game playing.
> 
> Even I'm not ready to go that far yet, although I can sympathize...
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-19: Require IPv6 Before Receiving Section 8 IPv4 Transfers

[Scott Leibrand]

This policy won’t help that goal. Applicants who have to jump through a hoop 
will ask “how high”, do the bare minimum (or outsource the task to someone who 
already has v6 and makes a business of announcing others’ netblocks just long 
enough to comply), and then stop there. This draft policy would very rarely 
help convince anyone to meaningfully deploy IPv6, and would not be worth making 
life difficult for everyone else. 

Scott

> On Nov 11, 2019, at 4:20 PM, Alan Batie  wrote:
> 
> On 11/11/19 4:13 PM, Scott Leibrand wrote:
>> If you want to make meaningful progress, you’re talking about “deploying 
>> enough IPv6 to not need another IPv4 block”: that requires either building 
>> something to be IPv6-only, or deploying enough IPv6 to reduce the size of 
>> the required NAT pool for your remaining IPv4 traffic. Both of those are 
>> hard and expensive on an enterprise network, so most enterprises have opted 
>> to “buy” so far.
> 
> I define meaningful progress in this context as making progress towards
> getting ipv6 widely enough deployed that ipv6-only sites can be
> reasonably useful in a general context.
> 
> This is probably the best justification for this policy I've seen yet:
> 
>> On 11/11/19 3:35 PM, hostmas...@uneedus.com wrote:
>> It also has an effect on enterprise customers whose CxO's do not want to
>> spend money on "unneeded" things.  Once IT tells management that they
>> cannot get any more IPv4 addresses without placing some IPv6 in place,
>> they will get support for adding IPv6 from the bean counters.  As long
>> as IPv6 is considered "Optional", a lot of Orgs will not spend the money
>> on it regardless of merit.
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-19: Require IPv6 Before Receiving Section 8 IPv4 Transfers

[Scott Leibrand]

If you want to make meaningful progress, you’re talking about “deploying enough 
IPv6 to not need another IPv4 block”: that requires either building something 
to be IPv6-only, or deploying enough IPv6 to reduce the size of the required 
NAT pool for your remaining IPv4 traffic. Both of those are hard and expensive 
on an enterprise network, so most enterprises have opted to “buy” so far.

Sure, meeting the “compliance” bar in this draft policy is easy. But that’s 
because it accomplishes approximately nothing. 

Scott

> On Nov 11, 2019, at 4:02 PM, Mark Andrews  wrote:
> 
> 
> 
>> On 12 Nov 2019, at 10:12, Scott Leibrand  wrote:
>> 
>> I think you underestimate the complexity of enterprise networking, and the 
>> relative lack of skill of the folks managing most enterprise networks, 
>> largely due to the fact that they can't enforce at-scale standardization as 
>> consumer networks do (so they can't just hire a small number of software 
>> architects to manage an entire network via automation).
> 
> I know one can turn on IPv6 along side IPv4 and gradually move stuff across 
> to supporting
> both IPv4 and IPv6.  I know that HTTP, SMTP and DNS servers have supported 
> IPv6 for over
> 2 decades.  DHCP servers have supported IPv6 nearly as long.  I know 
> firewalls have supported
> IPv6 for over 2 decades now.  I know Windows has supported IPv6 since Windows 
> XP. I know Apple,
> Oracle (Sun), VMS, Linux, … have supported IPv6 as long if not longer.  I 
> know turning on IPv6
> doesn’t mean turning off IPv4.  Most CDN’s support IPv6 these days as well 
> and you don’t have
> to be running IPv6 in house to project a IPv6 presence on the net.  Routers 
> have supported IPv6
> for decades as well though not at the $50 mark until recently.
> 
> Turning on IPv6 isn’t hard even if most it the plant isn’t using it.  The 
> front office can
> definitely use it just like homes use it today.  Getting to the state where 
> you are ready
> to go IPv6-only is hard as it requires every piece of equipment to support 
> IPv6, but don’t
> confuse the two.
> 
>> When it comes down to making a decision about whether to implement IPv6, the 
>> decision is usually "build vs. buy" - "build" a new network, new server 
>> infrastructure, etc., vs. "buy" more IPv4 addresses. On residential 
>> networks, they can "build" at a sufficient scale to be cheaper than 
>> "buying". On enterprise networks, the "buy" option is usually cheaper (and 
>> far less risky to the revenue-generating portions of the business).
> 
> In many cases it is just enable.
> 
>> There are ways to help change that cost/benefit tradeoff, but they involve 
>> solving hard problems of both the technical and organizational variety.  
>> This policy proposal does nothing to address them.
>> 
>> -Scott
>> 
>> On Mon, Nov 11, 2019 at 2:36 PM Mark Andrews  wrote:
>> Actually the arrogance of enterprises in not turning on IPv6 is astounding.
>> 
>> Their customers are being forced to share IP addresses not only between their
>> own machines but between machines from different customers because they can’t
>> take the simple step of turning on IPv6 on their servers.  No one else can
>> do that but them.
>> 
>> The world ran out if IPv4 address in 1995.  Stop gaps have kept IPv4 going 
>> since
>> then and they are getting worse. 20 years to plan to turn on IPv6 and they 
>> still
>> say they need more time.  Thats mega arrogance for you.
>> 
>> Mark
>> 
>>>> On 8 Nov 2019, at 12:08, Michel Py  
>>>> wrote:
>>> 
>>> Hi Jordi,
>>> 
>>>> I'm not sure if this is a love or a war declaration ... below ...
>>> 
>>> This is war, make no mistake.
>>> 
>>>> In fact, we should aim, as a community (RIRs, IETF, ICANN), to do as much 
>>>> as we can to start sunseting IPv4 now.
>>> 
>>> This is why we are at war. In 20 years, you have not yet captured 10% of 
>>> the enterprise market and you are talking about sunset ?
>>> Your arrogance is mind-boggling. You are fighting for the survival of IPv6. 
>>> You had your shot at it. For 20 years. Now want to kill my ecosystem, I 
>>> will thrown anything I have at yours. No matter how dirty it is. No matter 
>>> how much people will hate me. Not being nice anymore.
>>> 
>>> Michel.
>>> 
>>> ___
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Publ

Re: [arin-ppml] Draft Policy ARIN-2019-19: Require IPv6 Before Receiving Section 8 IPv4 Transfers

[Scott Leibrand]

I think you underestimate the complexity of enterprise networking, and the
relative lack of skill of the folks managing most enterprise networks,
largely due to the fact that they can't enforce at-scale standardization as
consumer networks do (so they can't just hire a small number of software
architects to manage an entire network via automation).

When it comes down to making a decision about whether to implement IPv6,
the decision is usually "build vs. buy" - "build" a new network, new server
infrastructure, etc., vs. "buy" more IPv4 addresses. On residential
networks, they can "build" at a sufficient scale to be cheaper than
"buying". On enterprise networks, the "buy" option is usually cheaper (and
far less risky to the revenue-generating portions of the business).

There are ways to help change that cost/benefit tradeoff, but they involve
solving hard problems of both the technical and organizational variety.
This policy proposal does nothing to address them.

-Scott

On Mon, Nov 11, 2019 at 2:36 PM Mark Andrews  wrote:

> Actually the arrogance of enterprises in not turning on IPv6 is astounding.
>
> Their customers are being forced to share IP addresses not only between
> their
> own machines but between machines from different customers because they
> can’t
> take the simple step of turning on IPv6 on their servers.  No one else can
> do that but them.
>
> The world ran out if IPv4 address in 1995.  Stop gaps have kept IPv4 going
> since
> then and they are getting worse. 20 years to plan to turn on IPv6 and they
> still
> say they need more time.  Thats mega arrogance for you.
>
> Mark
>
> > On 8 Nov 2019, at 12:08, Michel Py 
> wrote:
> >
> > Hi Jordi,
> >
> >> I'm not sure if this is a love or a war declaration ... below ...
> >
> > This is war, make no mistake.
> >
> >> In fact, we should aim, as a community (RIRs, IETF, ICANN), to do as
> much as we can to start sunseting IPv4 now.
> >
> > This is why we are at war. In 20 years, you have not yet captured 10% of
> the enterprise market and you are talking about sunset ?
> > Your arrogance is mind-boggling. You are fighting for the survival of
> IPv6. You had your shot at it. For 20 years. Now want to kill my ecosystem,
> I will thrown anything I have at yours. No matter how dirty it is. No
> matter how much people will hate me. Not being nice anymore.
> >
> > Michel.
> >
> > ___
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact i...@arin.net if you experience any issues.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-19: Require IPv6 Before Receiving Section 8 IPv4 Transfers

[Scott Leibrand]

I agree with David and at the moment am opposed to this policy proposal.

All of my recent employers have provided cloud / web infrastructure
services of one sort or another. Some of them provide those services over
IPv6, and some don't yet, depending on whether their customers demand it.
Independently, some of them provide dual-stacked IPv6 on employee LANs, and
some do not. The requirement dictated by this policy proposal would
essentially mean companies like my employers would need to provide
dual-stack IPv6 on at least one LAN accessible to the employees responsible
for interacting with ARIN. It would do absolutely nothing to encourage them
to do the much harder but mostly unrelated task of making their products
work with IPv6. It is, therefore, a pointless make-work requirement on them.

-Scott

On Wed, Nov 6, 2019 at 1:08 PM David Farmer  wrote:

> I oppose this policy.
>
> I'm not convinced of the efficacy of this policy, the policy's ability to
> produce its intended or desired result. I presume the intended result is to
> increase the deployment of IPv6. I'm not convinced that creating artificial
> hurdles for IPv4 will increase the deployment of IPv6 in any way. If the
> natural hurdle of having to go to the market to get IPv4 isn't enough to
> convince people to deploy IPv6, why would this artificial hurdle convince
> them? Given human nature, if this policy goes forward, I expect many people
> will turn on IPv6 to complete their IPv4 transfer and then simply turn IPv6
> off again, the end result does nothing for IPv6 deployment. Further, I
> suspect this policy is more likely to antagonize people against deploying
> IPv6 more than it is will incentivize them toward deploying IPv6.
>
> Please let's not go in this direction.
>
> Thanks.
>
> On Wed, Nov 6, 2019 at 11:55 AM ARIN  wrote:
>
>> On 1 November 2019, the ARIN Advisory Council (AC) accepted
>> "ARIN-prop-278: Require IPv6 Before Receiving Section 8 IPv4 Transfers"
>> as a Draft Policy.
>>
>> Draft Policy ARIN-2019-19 is below and can be found at:
>>
>> https://www.arin.net/participate/policy/drafts/2019_19/
>>
>> 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/participate/policy/pdp/
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/participate/policy/drafts/
>>
>> Regards,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> Draft Policy ARIN-2019-19: Require IPv6 Before Receiving Section 8 IPv4
>> Transfers
>>
>> Problem Statement:
>>
>> On 7 May 2007 the ARIN Board unanimously passed an IPv6 resolution. In
>> 2011, the last /8 blocks were assigned to the RIR’s and has now been
>> over 4 years since the IPv4 free pool was exhausted at ARIN.
>>
>> Now is the time for ARIN to require those who receive transferred IPv4
>> space to have in place an operational IPv6 network.
>>
>> Policy statement:
>>
>> In section 8.5.2, add the following language to the end of the paragraph
>> entitled “Operational Use”:
>>
>> Such operational network must at minimum include an allocation or
>> assignment by ARIN of IPv6 address space under the same Org ID receiving
>> the transferred IPv4 space. Such Org must be able to prove this IPv6
>> space is being routed by using it to communicate with ARIN.
>>
>> In the event the receiver provides a written statement from its upstream
>> that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.
>>
>> Timetable for Implementation: Upon Passage
>>
>> Anything Else:
>>
>> The following was included in the IPv6 resolution:
>>
>> BE IT RESOLVED, that this Board of Trustees hereby requests the ARIN
>> Advisory Council to consider Internet Numbering Resource Policy changes
>> advisable to encourage migration to IPv6 numbering resources where
>> possible.
>>
>> This proposal is part of an effort to encourage migration to IPv6.
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>
>
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 

Re: [arin-ppml] Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks - Clarifying Language

[Scott Leibrand]

If we have restrictions that are unenforced and routinely ignored, those
restrictions need to be removed (or enforced). To do otherwise creates an
environment where everyone is always in violation of the "letter of the
law", thereby reducing respect for the restrictions that we do want to
enforce. It puts at a disadvantage those who attempt to read and follow the
rules without having a tacit understanding of which rules are "really"
enforced. It also leaves open the possibility that the enforcing entity may
decide to start enforcing rules that were previously unenforced, perhaps
even in a capricious, corrupt, or otherwise less-than-ideal manner.

For all of those reasons, we need to ensure that our rules reflect what we
actually want ARIN to try to enforce. IMO the current policy requiring only
a VPN tunnel or unused switch port as a fig leaf to allow address leasing
is untenable and needs to be changed. I favor changing it by updating the
policy to reflect that address leasing is allowed, and what the
requirements should be.

-Scott

On Fri, Nov 1, 2019 at 2:23 PM Ronald F. Guilmette 
wrote:

> In message <30dbfe0c-f444-ec1c-54ad-62460ab56...@egh.com>,
> John Santos  wrote:
>
> >The proposal specifically relates to leasing IP addresses to recipients
> >who are NOT receiving connectivity from the lessor.
>
> As I said, I myself have no position on the proposal under discussion.
>
> As a general matter however, I have for many years now been concerned
> about the promulgation, within the various structures of Internet
> governance, of rules which, following adoption, are then rather trivially
> circumvented by parties having neither a care for nor a respect for the
> intent of the rules in question.
>
> For that reason, I do believe that it might be helpful to the discussion
> of the proposal if the alternatives were made completely clear.
>
> You've said that the status quo permits leasing in conjunction with
> connectivity.  But how is "connectivity" defined in this context,
> exactly?
>
> If you are a "provider" and I am your client, may you lease me IP addresses
> even if the IP addresses you lease me are ones that I get connectivity to
> from some -different- provider?
>
> Perhaps even more importantly, if leasing IP addresses in conjunction with
> "connectivity", however that term is currently defined, is currently A-OK,
> but leasing addresses NOT in conjunction with "connectivity" is currently
> prohibited, then who is enforcing that existing prohibition, how effective
> is the enforcement, and what are some recent examples of such enforcement?
>
> If in fact there is no actual enforcement of what I infer must be a current
> standing prohibition on leasing NOT in conjunction with connectivity, then
> what is the point of wasting time debating here the lifting of this
> prohibition, a prohibition which has no significance in actual practice
> anyway?
>
> Where I live, spitting on the sidewalk is illegal, but that law is never
> enforced, in practice, and thus I frequently see people spitting on the
> sidewalk.
>
> Given this context, I am not moved to passionately argue either for or
> against the repeal of our local anti-spitting ordinance, and would
> perfer instead to devote my time to more meaningful endeavors.
>
>
> Regards,
> rfg
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks - Clarifying Language

[Scott Leibrand]

In my opinion, it makes sense to allow leasing if we require that addresses
only be (re-)assigned to organizations who'll be using them on an
operational network. I think we're looking for language something like:


*ARIN allocates or assigns number resources to organizations via transfer
for the purpose of use on an operational network. Organizations receiving
number resources via transfer may reallocate or reassign number resources
to organizations that do not receive connectivity from the registrant for
use on another operational network.*

Further arguments inline below.

On Fri, Nov 1, 2019 at 9:19 AM  wrote:

> I also agree with what has been said, and am also opposed to the proposal.
>
> Some of the justification seems to be in the form of "I cannot afford to
> buy a car, so I demand that someone permit me to lease one".  Noone is
> going to get into the car leasing business unless they can make money.
> Generally the only money making segment is going to be the short term,
> since the lessors profit is going to make buying cheaper than leasing in
> the longer term.  I think the same applies to IP leasing.
>
> In the case of IP address leasing, the only major users of short term
> leases are abusers.  The advancers of this proposal talk of longer term
> leases to get discussion away from those abusers.  However, most of the
> time, someone wanting a long term lease would be better off to buy, as
> they can always sell them on again at the end of the need and often
> recover nearly all of their original investment, effectively having a
> short term use of the address space nearly free.


Nope, transferring purchased addresses and then re-transferring them after
< 12 months is disallowed by current rules (with the goal of preventing
speculation).

To extend your analogy, we currently disallow anyone from selling a car
they've owned for less than a year. Some people would really like to rent a
car for a shorter duration, so they do so. But the DMV has rules requiring
you to make regular use of your current cars before you can buy an
additional one, and doesn't consider short-term rental to be a legitimate
use, so they won't issue license plates for companies that rent out most of
their cars and want to obtain more cars to also rent out.

-Scott


>   I think the long term
> IP leasing business model will not work.
>
> The only valid leasing I can see is an entity that has excess address
> space that they expect to use in the future, and I think that case is
> already addressed in the current rules. They would also be unlikely to
> lease to someone that is an abuser, since they will have to live with the
> block reputation after the lease ends.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Fri, 1 Nov 2019, Fernando Frediani wrote:
>
> >
> > Exactly, and the main justification for this proposal to allow
> subleasing  is a total misuse of IP addressing and a try to privilege
> specific companies in
> > detriment to all others.
> >
> > I do not agree that legitimizing leasing as such increases accessibility
> to IPv4 space. Organization already have access to it by transfers. By
> allowing
> > leasing as such prices of both leasing and transfer has the potential to
> rise significantly as organizations will prefer much more to sublease than
> to
> > transfer which is logic to think that will increase pricing in general
> for both and which is only interesting to those who are involved in the
> transaction
> > and not to those who are seeking for IPv4 space and have already access
> via transfers.
> > The point about keeping the correct registry updated is not a
> justification either because this is already a obligation. If someone is
> not doing that or is
> > doing things in a different way is going against the current policies.
> Any organization who signed a contract when they became a member accepted
> to follow
> > these rules and they must bound to them, not the other way round.
> > As said there is not reasons to issue addresses to anyone who will not
> be using them on a operational network other than legitimate speculation of
> IP space.
> >
> > I consider the current text in NRPM as appropriate and therefore I
> oppose this proposal in full.
> >
> > Regards
> > Fernando
> >
> > On 01/11/2019 11:28, Owen DeLong wrote:
> >   I have trouble with both phrases.
> > Even if the resources are to be re-assigned to organizations or entities
> which do not receive connectivity from the original registrant, I see no
> > reason to issue addresses to anyone who will not be using them on an
> operational network.
> >
> > Owen
> >
> >
> >   On Oct 31

Re: [arin-ppml] Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks - Clarifying Language

[Scott Leibrand]

On Thu, Oct 31, 2019 at 3:03 PM Kiran Malancharuvil 
wrote:

> Dear All,
>
> Prior to tomorrow's community discussion of Draft Policy ARIN-2019-18, I
> wanted to offer some clarification and propose some language for
> consideration to address questions posed on the PPML.
>
> Regarding the question over the intended meaning of "non-connected
> networks", I will clarify that I mean this policy to refer to re-assignment
> to organizations and entities which do not receive connectivity from the
> original registrant.
>
> As such, I wanted to offer the following alternative edit to 8.5.2:
>
> 8.5.2 Operational Use
>
> ARIN allocates or assigns number resources to organizations via transfer
> *primarily* for the purpose of use on an operational network, *but may
> allocate or assign number resources to organizations for other
> purposes, including re-assignment to organizations and entities which do
> not receive connectivity from the original registrant.*
>
>
I believe this is consistent with the intent of 2019-18, and I would
support this language.


>
> Alternatively, and more simply, since the sentence referencing
> "non-connected networks" starts with "including" and is therefore not meant
> to be an exclusive "other purpose", but rather illustrative, we can remove
> it entirely.  That option would read:
>
> 8.5.2 Operational Use
>
> ARIN allocates or assigns number resources to organizations via transfer
> *primarily* for the purpose of use on an operational network, *but may
> allocate or assign number resources to organizations for other purposes.  *
>
> I believe this is materially different than the text above, in that it
would give ARIN permission to approve transfers for any reason whatsoever.
ARIN in the past has interpreted such ambiguity in favor of allowing
whatever is not expressly prohibited. As such, I don't think this language
accomplishes the original intent, and would oppose it.

-Scott


> **please note that the online version of the policy proposal reads "solely
> primarily" instead of "primarily".  This is a typo due to originally
> proposing the language with the word "solely" in strike-through text
> (solely), which did not translate.  *
>
> Further, I want to clarify, as the original author of the proposal, that
> the key intent of the policy is to acknowledge that small and medium-sized
> businesses have a need for IPv4 space, but often cannot afford to buy space
> in the current market.  Legitimizing a subleasing market increases
> accessibility to IPv4 space, and opens the market to business solutions to
> facilitate safe, trusted subleasing practices, including keeping the
> correct registry updated.
>
> Thanks all for the continued discussion.
>
> Best,
>
> Kiran
> --
> Kiran Malancharuvil
> Open-i Advisors
> p:  415 419 9138
> http://openiadvisors.com
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks

[Scott Leibrand]

+1 to everything David just said.

Do y'all have what you need to draft another version of this proposal
tightening up the language to be consistent with this? Or does someone here
need to propose text?

-Scott

On Tue, Oct 1, 2019 at 1:32 PM David Farmer  wrote:

>
> On Tue, Oct 1, 2019 at 9:50 AM Scott Leibrand 
> wrote:
>
>> Should we make 2019-18 clearly say that reallocation or reassignment to
>> non-connected networks who will themselves make operational use of the
>> leased addresses is considered efficient use? Basically, keep the “use”
>> requirement around reassignments the same as it is now, and just state
>> clearly that non-connected reassignments are ok?
>>
>> Scott
>>
>
> I support language like this, but I do not support removal of the "use"
> requirement, someone has to be using the addresses, if not there is no
> basis for an assignment or allocation, or reassignment or reallocation.
>
> Furthermore, RFC2008 introduced the address lending model, and this has
> been the primary model of acquiring address space for regular users ever
> since. RFC2008 does expects the relationship to be more than just for
> address space, it expects connectivity is being provided as well.
> Furthermore, that the address will be returned when the connectivity
> ceases.  However, the reason for this is aggregation, if the user of the
> address space isn't connected then the provider can't aggregate.
>
> However, in a world without a free-pool aggregation as a primary concern
> has effectively gone out the window. We are now routing ever smaller bits
> and pieces of address space, we have to, it's called recycling. Further, we
> have decided that routing policy is not ARIN or the other RIR's business,
> and aggregation is routing policy. Therefore address space as the only
> relationship between the leasor and leasee, while not ideal, it is
> impractical for this to be a policy violation any longer.
>
> If I've been using address space for years and I want to change my
> provider and my provider is willing to allow me, probably for a fee, to
> keep using the address space they have loaned me for years, the facts on
> the ground today make it impractical for this to be a policy violation.
> Further, it that isn't a policy violation, then a new address only lease
> transaction shouldn't be either.
>
> Guys we live is a post-free-pool world some ideas have to change with the
> facts on the ground.  Address leasing absent connectivity is a fact of life
> in a post-free-pool world.
> That doesn't mean I willing to give up on some kind of basic "use"
> requirement, again someone has to be using the addresses, if not there is
> no basis for an assignment or allocation, or a reassignment or reallocation
> either.
>
> Thanks
>
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks

[Scott Leibrand]

Should we make 2019-18 clearly say that reallocation or reassignment to 
non-connected networks who will themselves make operational use of the leased 
addresses is considered efficient use? Basically, keep the “use” requirement 
around reassignments the same as it is now, and just state clearly that 
non-connected reassignments are ok?

Scott

> On Oct 1, 2019, at 7:40 AM, Mike Burns  wrote:
> 
> Albert wrote:
> It was always understood you were supposed to turn back in unused numbers. 
> The market is one way to do that, by turning your unused addresses over to 
> someone who can use them. Leasing does not meet that standard in my mind.
> 
> Numbers are for operational networks, not for speculators.
> 
> 
> Hi Albert and thanks for your thoughts. My I ask why the transfer market 
> turns unused addresses over to someone who can use them, but the leasing 
> market does not?  Do you place such a premium on deal format? What if it's a 
> lease-to-own arrangement? What if it's a 10 year lease? What is different, 
> except for financial issues, between transfers and leases, in the context of 
> bringing unused addresses into use on an operational network?
> 
> Why do you think speculators would be antithetical to using numbers on 
> operational networks? I genuinely do not understand, unless you are referring 
> to that eternal bogeyman, the hoarder. You shouldn't oppose policy in this 
> regard until and unless somebody, somewhere has evidence of IPv4 hoarding by 
> speculators, ever.  I define speculator as somebody who invests money into 
> IPv4 addresses seeking to profit from that investment. Can somebody even 
> offer a description of how hoarding would work *in this market* to a 
> speculator's benefit?
> 
> Regards,
> Mike
> 
> 
> 
> 
> 
> 
> 
> 
>> On Mon, 30 Sep 2019, Mike Burns wrote:
>> 
>> Hi Fernando,
>> 
>> Let me address the two items highlighted in your reply below.
>> 
>> First is the reduction of ARIN to nothing more than a registration 
>> operation. What is wrong with that? RFC2050 said the primary purpose of an 
>> RIR is registration. We need to keep the numbers unique or everything fails. 
>> ARIN should indeed reduce itself to registering transfers and doing what it 
>> can to maintain accurate registration per our primary stewardship role. All 
>> else is subservient, including conservation. But we have addressed 
>> conservation.  RIPE has been reduced to a registration operation, to use 
>> your term. What is so wrong with RIPE?
>> 
>> Second is the point that one of the business cases for leasing is for 
>> spamming. This is something to consider, but I would like for you to put 
>> yourself into the position of a Lessor. The Lessor knows  his blocks will 
>> lose value if they are blacklisted, so they take steps to mitigate this. For 
>> example, one notable lessor charges a $20 fee for every abuse complaint on a 
>> leased block. The Lessee pays the $20 fee and most of it is paid to the 
>> Lessor as compensation. This disincentivizes spamming on leased blocks. A 
>> Lessor who gets tricked into leasing to a spammer will find his block 
>> devalued significantly. He can get it delisted one, maybe twice if he can 
>> spin a good story. After that, no more for that owner. So the owners have 
>> penalties and usage terms built into the lease contract, or they get 
>> prepayment for many months in advance, or they lease large blocks which are 
>> not appealing to spammers. The point is this is a valid argument against 
>> changing policy to support leasing!
> , but the problems are long-known and the market has applied corrections.  On 
> the other hand, spammers like to hijack too, and having the ability to define 
> a hijack as being non-compliant with a lease policy will enable ARIN to 
> pressure the address holder for a policy violation if pressure from that side 
> helps.
>> 
>> Regards,
>> Mike
>> 
>> 
>> 
>> -Original Message-
>> From: ARIN-PPML  On Behalf Of Fernando 
>> Frediani
>> Sent: Monday, September 30, 2019 4:36 PM
>> To: arin-ppml@arin.net
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2019-18: LIR/ISP 
>> Re-Assignment to Non-Connected Networks
>> 
>>> On 30/09/2019 15:36, hostmas...@uneedus.com wrote:
>>> 
>>> Currently, the ability to obtain IPv4 resources is constrained by the 
>>> requirement to prove to ARIN that you need the addresses for your 
>>> operational use in a network, which will be claimed to be no unneeded 
>>> once the "operational use" requirement is gone, leaving ARIN to be 
>>> nothing more than a registration operation.
>> Excellent point raised. Couldn't agree more !
>>> 
>>> While this is claimed to reduce one problem with leasing IPv4 
>>> addresses (lack of registration and associated abuse contacts) it 
>>> causes other issues.  Often network abusers lease addresses for 
>>> abuse, dumping them and leasing others when they get blacklisted.
>> And this too. Actually this is a well known issue.
>>> 
>>> 
>>> 
>>> 
 On Mon, 30 

Re: [arin-ppml] Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks

[Scott Leibrand]

I support the spirit of this policy.

I'm not sure the Option 2 edits to 8.5.2 Operational Use would have the
intended effect. It reads that "ARIN ... may allocate or assign number
resources to organizations for other
purposes, including re-assignment to non-connected networks", which doesn't
require ARIN to change policy in any way, nor AFAICT does it conform to the
proposed 2.4 language that "LIRs may also assign address space to other
organizations or customers that request it for use in an operational
network."

Perhaps something like this would accomplish the desired ends?

8.5.2 Operational Use

ARIN allocates or assigns number resources to organizations via transfer
solely for the purpose of use on, or reallocation/reassignment to,
operational networks.

-Scott

On Tue, Sep 24, 2019 at 1:41 PM ARIN  wrote:

> On 19 September 2019, the ARIN Advisory Council (AC) accepted
> "ARIN-prop-277: LIR/ISP Re-Assignment to Non-Connected Networks" as a
> Draft Policy.
>
> Draft Policy ARIN-2019-18 is below and can be found at:
>
> https://www.arin.net/participate/policy/drafts/2019_18/
>
> 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/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks
>
> Problem Statement:
>
> Businesses have a need to lease IPv4 space for limited periods of time,
> as evidenced by a robust (technically prohibited) subleasing market. The
> lack of legitimization of the subleasing market hinders innovation,
> research, reporting, and the development of rules/industry best
> practices to ensure identifiability and contactability.
>
> Policy statement:
>
> ORIGINAL POLICY LANGUAGE
>
> 2.4. Local Internet Registry (LIR)
>
> A Local Internet Registry (LIR) is an IR that primarily assigns address
> space to the users of the network services that it provides. LIRs are
> generally Internet Service Providers (ISPs), whose customers are
> primarily end users and possibly other ISPs.
>
> PROPOSED POLICY LANGUAGE
>
> A Local Internet Registry (LIR) is an IR that primarily assigns address
> space to the users of the network services that it provides. LIRs are
> generally Internet Service Providers (ISPs), whose customers are
> primarily end users and possibly other ISPs.
>
> LIRs may also assign address space to other organizations or customers
> that request it for use in an operational network.
>
> ORIGINAL POLICY LANGUAGE
>
> 8.5.2 Operational Use
>
> ARIN allocates or assigns number resources to organizations via transfer
> solely for the purpose of use on an operational network.
>
> PROPOSED POLICY LANGUAGE
>
> Option 1 : Remove 8.5.2 entirely
>
> Option 2 : Edit as follows
>
> 8.5.2 Operational Use
>
> ARIN allocates or assigns number resources to organizations via transfer
> solely primarily for the purpose of use on an operational network, but
> may allocate or assign number resources to organizations for other
> purposes, including re-assignment to non-connected networks .
>
> Comments:
>
> Timetable for implementation: Immediate
>
> Anything Else:
>
> The legitimization of a subleasing market for IPv4 has numerous business
> and community benefits, including (but not limited to):
>
> - Allowing organizations to efficiently utilize IPv4 space without
> transferring space permanently;
> - Allowing organizations to obtain IPv4 space for a limited time in
> order to facilitate transition to IPv6;
> - Allowing organizations to develop enforceable acceptable use policies
> in a previously lawless illegitimate space;
> - Allowing the community to develop reporting and recording standards
> and/or best practices to the benefit of preserving the integrity of IPv4
> address space.
> - We would like to engage further with the ARIN community to discuss the
> current state of the unauthorized subleasing market, and how this
> proposed policy change would both update ARIN policies to reflect the
> reality of the subleasing market, and positively address business and
> community concerns.
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience 

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

[Scott Leibrand]

Ok, glad to hear the intent regarding automated processing is closer to
what I would consider appropriate.

How about:

"All emails sent to this address must be processed appropriately,
ultimately reaching a human processor who evaluates each message that
cannot be appropriately handled by any automated systems."

And what about the requirement that "That the mailbox is regularly
monitored and that abuse reports receive a response."? What kind of
response is intended there? It seems to imply something more than the
"initial automatic processing" mentioned earlier.

-Scott

On Tue, Jul 16, 2019 at 10:05 AM JORDI PALET MARTINEZ via ARIN-PPML <
arin-ppml@arin.net> wrote:

> Hi Scott,
>
>
>
> I guess there is some misunderstanding in that part of the text. May be
> “ultimately” is not doing the intended “work”. The idea is “last resort”.
>
>
>
> The idea is not that messages are processed only by humans. If it can be
> automatically processed that’s fine and perfect. The goal is that if “that
> doesn’t work” then somebody need to take care of it.
>
>
>
> See 3.6.6.3:
>
> 2. Avoids exclusively automated processing.
>
>
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 16/7/19 18:39, "ARIN-PPML en nombre de Scott Leibrand" <
> arin-ppml-boun...@arin.net en nombre de scottleibr...@gmail.com> escribió:
>
>
>
> 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 many entirely appropriate
> automated actions that well-run ISPs take in response to abuse reports that
> don't involve "a human processor who evaluates each message received", and
> don't necessarily require a response to the original reporter.  The first
> project I undertook at my first job was writing a mostly-automated abuse
> processing system that properly dealt with all incoming abuse@ email, but
> would not be compliant with this policy language as written because it took
> fully automated action when appropriate.
>
>
>
> If you want to impose such onerous requirements on ISPs, the appropriate
> method to do so is via legislation (as was done for the DMCA), not by ARIN
> number resource administration policy.
>
>
>
> -Scott
>
>
>
> On Tue, Jul 16, 2019 at 8:29 AM ARIN  wrote:
>
> The following has been revised and retitled:
>
> * Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts
>
> Formerly:
>
> * Draft Policy ARIN-2019-5: Validation of Abuse-mailbox
>
> Revised text is below and can be found at:
> https://www.arin.net/participate/policy/drafts/2019_5/
>
> 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/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts
>
> Problem Statement:
>
> The current policy, “3.6. Annual Validation of ARIN’s Public Whois Point
> of Contact Data” does not provide sufficient validation of the actual
> availablility of the abuse mailbox.
>
> As a result, some resource-holders (LIRs and end-users) might not keep
> this contact information up to date, or might use a non-responsive
> mailbox which may be full or not actively monitored. Some may even
> respond only to ARIN emails.
>
> In practice, this contact becomes ineffective for reporting abuse and
> generally gives rise to security issues and costs for the victims.
>
> Furthermore, POCs are verified only every year and provide a very
> relaxed response time (60 days).
>
> Finally, the proposal seeks to standardize the abuse-c/abuse-mailbox as
> a pointer to an actual abuse POC in order to facilitate development of
> tools that can work across regions.
>
> Proposed Policy Statement:
>
> Add to section 3.6 of the NRPM as follows:
>
>

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

[Scott Leibrand]

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 many entirely appropriate
automated actions that well-run ISPs take in response to abuse reports that
don't involve "a human processor who evaluates each message received", and
don't necessarily require a response to the original reporter.  The first
project I undertook at my first job was writing a mostly-automated abuse
processing system that properly dealt with all incoming abuse@ email, but
would not be compliant with this policy language as written because it took
fully automated action when appropriate.

If you want to impose such onerous requirements on ISPs, the appropriate
method to do so is via legislation (as was done for the DMCA), not by ARIN
number resource administration policy.

-Scott

On Tue, Jul 16, 2019 at 8:29 AM ARIN  wrote:

> The following has been revised and retitled:
>
> * Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts
>
> Formerly:
>
> * Draft Policy ARIN-2019-5: Validation of Abuse-mailbox
>
> Revised text is below and can be found at:
> https://www.arin.net/participate/policy/drafts/2019_5/
>
> 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/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2019-5: Validation of POCs Referenced as Abuse Contacts
>
> Problem Statement:
>
> The current policy, “3.6. Annual Validation of ARIN’s Public Whois Point
> of Contact Data” does not provide sufficient validation of the actual
> availablility of the abuse mailbox.
>
> As a result, some resource-holders (LIRs and end-users) might not keep
> this contact information up to date, or might use a non-responsive
> mailbox which may be full or not actively monitored. Some may even
> respond only to ARIN emails.
>
> In practice, this contact becomes ineffective for reporting abuse and
> generally gives rise to security issues and costs for the victims.
>
> Furthermore, POCs are verified only every year and provide a very
> relaxed response time (60 days).
>
> Finally, the proposal seeks to standardize the abuse-c/abuse-mailbox as
> a pointer to an actual abuse POC in order to facilitate development of
> tools that can work across regions.
>
> Proposed Policy Statement:
>
> Add to section 3.6 of the NRPM as follows:
>
> 3.6.6 Policies specific to Abuse Contacts
>
> 3.6.6.1 Abuse Contact Information
>
> The Abuse Contact will reference a POC object holding Abuse contact
> information. Each org must have an Abuse Contact. Optionally, resource
> records may point directly to an Abuse Contact as an override to the
> corresponding organizational Abuse Contact specific to that resource.
>
> 3.6.6.2 Email Addresses in POCs used as Abuse Contacts
>
> Emails sent to this address must ultimately reach a human processor who
> evaluates each message received.
>
> Messages cannot be automatically filtered because legitimate abuse
> reports may include contents which would trigger such filters.
>
> Reports to this mailbox may undergo initial automatic processing for the
> following purposes:
>
> * An automated reply assigning a ticket number, applying classification
> procedures, etc.
> * An indication of the required information for an abuse report to be
> processed, such as pertinent logs, copy of the spam message with full
> headers, or any other relevant evidence of abuse.
> * The intent is to facilitate automated abuse reporting in consistent
> formats lowering cost for both victims and those processing legitimate
> abuse reports.
>
> 3.6.6.3 Abuse Contact Validation Objectives Staff must develop a
> validation procedure which accomplishes all of the following objectives:
>
> 1. A simple process which allows POCs to validate that the validation
> request is actually from ARIN.
> 2. Avoids exclusively automated processing.
> 3. Confirms that the person performing the validation understands the
> procedure and relevant policies. That the mailbox is regularly monitored
> and that abuse reports receive a response.
> 4. Maximum validation period is 15 days.
> 5. If validation fails, escalate to the LIR for an additional 15 days.
>
> The initial and escalation 

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

[Scott Leibrand]

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 transferred to another RIR. 

Support.

Scott

> On Jul 15, 2019, at 1:32 PM, Joe Provo  wrote:
> 
> 
> 
> Hey folks,
> 
> Like several other proposals, we seem to have been
> hit by the summer slump considering the following.
> 
> There was a single posted objection, and it isn't
> clear if lack of activity stems from 
> - uninterest
> - interest in seeing 2019-13 move instead
> - interest in seeing 2019-4 move instead
> - something else
> 
> Thanks in advance for more input!
> 
> Joe
> 
> 
>> On Tue, May 21, 2019 at 02:02:14PM -0400, ARIN wrote:
>> On 16 May 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-272: 
>> M Legal Jurisdiction Exclusion" as a Draft Policy.
>> 
>> Draft Policy ARIN-2019-12 is below and can be found at:
>> https://www.arin.net/participate/policy/drafts/2019_12/
> [snip]
>> Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
>> 
>> Problem Statement:
>> 
>> M activity sometimes results in a surviving legal entity that is not 
>> in ARIN service region, but may prefer to continue the pre-existing 
>> relationship with ARIN.
>> 
>> Example: Imagine a case where a global company has decided to 
>> discontinue service in the ARIN service region (shuttering ARIN region 
>> offices laying off ARIN region employees, and canceling ARIN region 
>> customers) and repurpose the network resources and number resources in 
>> the rest of its global footprint. During restructuring the company 
>> concentrates its holdings in its European subsidiary, and then dissolved 
>> its US legal entity.
>> 
>> Imagine a case where a global company has decided to divest its service 
>> in the ARIN region (selling all ARIN region offices, all ARIN region 
>> network assets, all ARIN service region customers, all number resources 
>> used in the ARIN (associated with previous noted sale of network and 
>> customers), but retaining ARIN issued resources in use outside of the 
>> ARIN service region. During restructuring the company concentrates its 
>> holdings which are not in us in the ARIN service region in its European 
>> subsidiary, and then sells off its US legal entity (including the 
>> network, customers, addresses in use, etc) dissolved its US legal entity.
>> 
>> Policy Statement:
>> 
>> Add the following to section 8.2
>> 
>> M activity resulting in the surviving legal entity which is not 
>> incorporated in the ARIN service region will be permitted to hold number 
>> resources directly allocated or assigned by ARIN.
>> 
>> Comments:
>> 
>> Timetable for implementation: Immediate
>> 
>> Anything Else This proposal may be overtaken by a more general approach 
>> to ARIN membership legal jurisdiction exclusion
> 
> 
> 
> -- 
> Posted from my personal account - see X-Disclaimer header.
> Joe Provo / Gweep / Earthling 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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 is to allow IPv6 networks access to IPv4 resources so that the 
> users on these networks can connect to IPv4 resources.
> 
> Current practice for CGnat generally use a block of 4.10 IPv4 resources to 
> provide such interconnect for many /64 networks.  Giving them a /21 to be 
> able to have a CGnat at each site does not seem a good use of this block. 
> This is more than what was proposed for the regular waiting list, limited to 
> a /22. The goal of the block is for IPv4 connectivity until a future time 
> when IPv4 is no longer the primary transport on the internet.  It was 
> intended to be a shared block, and not one where each user could have their 
> own IPv4 address.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
>> On Mon, 15 Jul 2019, Owen DeLong wrote:
>> 
>> Hello, everyone.
>> 
>> The AC is currently considering this draft policy which would provide for 
>> Multiple Discrete Networks to be able to get more than one block under 4.10 
>> for up to 8 discrete sites within a six month period.
>> 
>> So far, there has been little comment on the list. The AC would like to 
>> encourage feedback whether positive or negative in nature about this 
>> proposal (though always constructive in any case).
>> 
>> Thanks,
>> 
>> Owen
>> 
>> Proposal text:
>> 
>> Problem Statement:
>> Currently, applicants for IPv4 resources under section 4.10 of the NRPM who 
>> do so under a single OrgID of the NRPM may only obtain one /24 every six 
>> months for the OrgID, even in the case where multiple discrete networks 
>> (MDNs) as defined in section 4.5 of the NRPM are grouped under that OrgID. 
>> On the other hand, where MDNs are held under different OrgIDs associated the 
>> same entity, the six-month constraint would apply to each discrete network 
>> separately. This results in unfair allocations of resources based solely on 
>> how entities choose to associate MDNs with their OrgIDs. This policy 
>> rectifies that problem by placing MDNs on an equal footing for the purpose 
>> of section 4.10 allocations regardless of how they are grouped by OrgID by 
>> the same ultimate entity.
>> Policy Statement:
>> Bullet 1. under section 4.10 of the NRPM is amended to read:
>> the applicant may not have received resources under this policy in the 
>> preceding six months, except to the extent that the applicant is r
>> equesting resources for a discrete network in respect of which it has not 
>> received any resources under this policy in the preceding six months;
>> Add a new bullet 6 that reads:
>> An applicant requesting multiple allocations under this policy to support 
>> Multiple Discrete Networks, as defined under Section 4.5, may not receive 
>> more than the equivalent of a /21 of IPv4 address space in any one six-month 
>> period hereunder.
>> Timetable for Implementation: Immediate
>> Anything Else:
>> To what extent should the passage of this policy be contingent or 
>> independent of whether any ultimate cap is imposed on the total quantity of 
>> IPv4 resources that an entity can obtain under section 4.10 regardless of 
>> the number of OrgIDs associated with the entity or number of MDNs it holds.
>> 
>> ==
>> 
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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 for
> Multiple Discrete Networks to be able to get more than one block under 4.10
> for up to 8 discrete sites within a six month period.
>
> So far, there has been little comment on the list. The AC would like to
> encourage feedback whether positive or negative in nature about this
> proposal (though always constructive in any case).
>
> Thanks,
>
> Owen
>
> Proposal text:
>
> Problem Statement:
> Currently, applicants for IPv4 resources under section 4.10 of the NRPM
> who do so under a single OrgID of the NRPM may only obtain one /24 every
> six months for the OrgID, even in the case where multiple discrete networks
> (MDNs) as defined in section 4.5 of the NRPM are grouped under that OrgID.
> On the other hand, where MDNs are held under different OrgIDs associated
> the same entity, the six-month constraint would apply to each discrete
> network separately. This results in unfair allocations of resources based
> solely on how entities choose to associate MDNs with their OrgIDs. This
> policy rectifies that problem by placing MDNs on an equal footing for the
> purpose of section 4.10 allocations regardless of how they are grouped by
> OrgID by the same ultimate entity.
> Policy Statement:
> Bullet 1. under section 4.10 of the NRPM is amended to read:
> the applicant may not have received resources under this policy in the
> preceding six months, except to the extent that the applicant is r
> equesting resources for a discrete network in respect of which it has not
> received any resources under this policy in the preceding six months;
> Add a new bullet 6 that reads:
> An applicant requesting multiple allocations under this policy to support
> Multiple Discrete Networks, as defined under Section 4.5, may not receive
> more than the equivalent of a /21 of IPv4 address space in any one
> six-month period hereunder.
> Timetable for Implementation: Immediate
> Anything Else:
> To what extent should the passage of this policy be contingent or
> independent of whether any ultimate cap is imposed on the total quantity of
> IPv4 resources that an entity can obtain under section 4.10 regardless of
> the number of OrgIDs associated with the entity or number of MDNs it holds.
>
> ==
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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 is not subject to transfer restrictions?

-Scott

On Mon, Jul 15, 2019 at 11:21 AM Kerrie Vassall-Richards <
kerriearicha...@gmail.com> wrote:

> Good day everyone,
>
> I am seeking community input on *Draft Policy ARIN-2019-10: Inter-RIR M 
> *since the last post on this policy on May 21, 2019 there has not been any 
> conversation around it. As primary shepherd I need to have a good sense of 
> the direction that the community wants to take in regards to this policy. As 
> a starting point I would like to hear from the community if it is thoght the 
> policy is:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
>
>1. Draft Policy ARIN-2019-10 is below and can be found at: 
> https://www.arin.net/participate/policy/drafts/2019_10/
>2. NRPM Version 2019.2 - 10 July 2019 can be found here: 
> https://www.arin.net/participate/policy/nrpm/
>3. The Specific section of the NRPM affected by this policy can be found 
> here: 
> https://www.arin.net/participate/policy/nrpm/#8-2-mergers-acquisitions-and-reorganizations
>
> As a reminder please see the problem and the policy statements
> Problem Statement:
>
> Merger, acquisition, or reorganization activity sometimes results in a
> restructuring where company resources, the management of number
> resources, or the use of number resources are concentrated outside the
> ARIN service region. In this case it may be desirable for the current
> legal entity or a legal entity that is a parent, child or sister to move
> the servicing of the number resources to a different RIR.
>
> Policy Statement:
> *Add to section 8.2:*
>
> When merger, acquisition, or reorganization activity results in
> surviving legal entity that is incorporated outside the ARIN service
> region, or focused outside the ARIN service region, or is merging with
> an organization that already has a relationship with another RIR, then
> resources may be moved to another RIR in accordance with the receiving
> RIR’s policies.
>
> I look forward to hearing more from everyone on this policy.
>
> Warm regards
>
> Kerrie
>
>
>
>
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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 understand it, "actual" in the
original proposer's native language best translates to "current" in English
(and "real" translates to "actual").

-Scott

On Wed, Jun 26, 2019 at 4:35 PM David Farmer  wrote:

> I agree with others, the problem statement needs to be simplified and
> clarified significantly. Furthermore, the only change in the policy text
> needed is to add "authroized" to the current text, as in "authorized third
> parties".  More provided inline;
>
> On Tue, Jun 25, 2019 at 4:18 PM ARIN  wrote:
>
>> On 20 June 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-275:
>> Hijacking Authorization Not-intended" as a Draft Policy.
>>
> ...
>
>> Draft Policy ARIN-2019-15: Hijacking Authorization Not-intended
>>
>> Problem Statement:
>>
>> When prop-254 (Clarification on IPv6 Sub-assignments), it was not
>> related, neither intended, to modify the “exclusivity” criterion.
>>
>
> It is not clear to me what this paragraph is intended to mean.
>
>
>> Of course, it was not intended to provide an explicit authorization for
>> incidental or transient uses of address space by third parties, which in
>> fact it is a hijacking of addresses.
>>
>
> In no way is "explicit authorization" provided to do anything like
> hijacking a prefix by the statement called out.  At best, you could argue
> that "implicit authorization" is provided and that is a rather perverse
> interpretation of the text.
>
> Explicit - stated clearly and in detail, leaving no room for confusion or
> doubt.
> Implicit - implied though not plainly expressed.
>
> However, I would argue that the whole statement implies authorization by
> the recipient for anything and the fix to any problems is to explicitly
> restrict the statement to "authorized third parties". Changing much more
> than that risks changing the meaning in subtle and unintended ways, and it
> was hard enough to agree on what we have now.
>
> However, surprisingly, the resulting text (last paragraph of the NRPM
>> section 2.5), after the ARIN AC editorial process, is doing that.
>>
>> This policy proposal tries to fix this specific text in the NRPM section
>> 2.5 to avoid that misinterpretation.
>>
>
> Maybe replace the whole problem statement with;
>
> ARIN-2018-4: Clarification on Temporary Sub-Assignments, could be
> perversely interrupted to imply the unauthorized use of a prefix "by third
> parties" is allowed, such as prefix hijacking. This is clearly not
> intended. The solution to this is to explicitly restrict the statement to
> "authorized third parties."
>
> Policy Statement:
>>
>> Actual Text
>>
>
> This should be "Current Text", as the intent of any policy proposal is to
> change the "Actual Text", that is the intent is for the "New Text" to
> become the "Actual Text".
>
>
>> Note that the incidental or transient use of address space by third
>> parties shall not be considered a reassignment or a violation of the
>> exclusive use criterion.
>>
>> New Text
>>
>> Note that the incidental or transient use of address space by third
>> parties, within the network of the recipient organization, shall not be
>> considered a reassignment or a violation of the exclusive use criterion
>>
>
> This text possibly solves prefix hijacking but probably creates new
> issues. However, if the original text implies prefix hijacking is
> permitted, it also implies unauthorized attachments to a network are
> permitted, and this proposed text wouldn't fix that problem.
>
> I think the "New Text" should be the following;
>
> Note that the incidental or transient use of address space by authorized
> third parties shall not be considered a reassignment or a violation of the
> exclusive use criterion.
>
>
>> Timetable for Implementation: Immediate
>>
>> Anything Else:
>>
>> Situation in other regions: There is not equivalent explicit hijacking
>> authorization in other RIRs.
>>
>
> Again I take exception to "explicit hijacking authorization", there is
> nothing in the entire NRPM that explicitly authorizes the hijacking of
> prefixes, let alone the current statement called out. I'd suggest striking
> this paragraph.
>
> Thanks.
>
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing 

Re: [arin-ppml] Draft Policy ARIN-2019-10: Inter-RIR M

[Scott Leibrand]

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 space) should be transferable this way. 

Scott

> On Jun 18, 2019, at 9:38 AM, Chris Woodfield  wrote:
> 
> Hello PPML,
> 
> The Advisory Council is seeking statements of support or opposition to the 
> below draft policy, which so far have not been seen on PPML. I’d advise the 
> community to consider the following questions:
> 
> 1. Is the problem statement a valid and/or likely occurrence that would 
> require a change of policy to address?
> 2. Is the proposed text to address the problem statement a valid means to do 
> so? Are there other approaches the community would like the AC to consider?
> 3. Is there any potential deleterious impact should this language be adopted 
> into the NRPM?
> 
> We look forward to hearing the community’s response.
> 
> Thank you,
> 
> -Chris Woodfield
> ARIN Advisory Council
> 
>> On May 21, 2019, at 11:01 AM, ARIN  wrote:
>> 
>> On 16 May 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-270: 
>> Inter-RIR M" as a Draft Policy.
>> 
>> Draft Policy ARIN-2019-10 is below and can be found at:
>> https://www.arin.net/participate/policy/drafts/2019_10/
>> 
>> 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/participate/policy/pdp/
>> 
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/participate/policy/drafts/
>> 
>> Regards,
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> 
>> Draft Policy ARIN-2019-10: Inter-RIR M
>> 
>> Problem Statement:
>> 
>> Merger, acquisition, or reorganization activity sometimes results in a 
>> restructuring where company resources, the management of number resources, 
>> or the use of number resources are concentrated outside the ARIN service 
>> region. In this case it may be desirable for the current legal entity or a 
>> legal entity that is a parent, child or sister to move the servicing of the 
>> number resources to a different RIR.
>> 
>> Example:
>> 
>> Imagine a case where a global company has decided to discontinue service in 
>> the ARIN service region (shuttering ARIN region offices laying off ARIN 
>> region employees, and canceling ARIN region customers) and repurpose the 
>> network resources and number resources in the rest of its global footprint.
>> 
>> Imagine a case where a global company has decided to divest its service in 
>> the ARIN region (selling all ARIN region offices, all ARIN region network 
>> assets, all ARIN service region customers, all number resources used in the 
>> ARIN (associated with previous noted sale of network and customers), but 
>> retaining ARIN issued resources in use outside of the ARIN service region.
>> 
>> Policy Statement:
>> 
>> Add to section 8.2:
>> 
>> When merger, acquisition, or reorganization activity results in surviving 
>> legal entity that is incorporated outside the ARIN service region, or 
>> focused outside the ARIN service region, or is merging with an organization 
>> that already has a relationship with another RIR, then resources may be 
>> moved to another RIR in accordance with the receiving RIR’s policies.
>> 
>> Comments:
>> 
>> Timetable for implementation: Immediate
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] IP leasing policy

[Scott Leibrand]

The portion that would be within scope as ARIN policy would be any requirements 
to publish reassignment information in the ARIN database. However, we would 
need further discussion on whether/how such requirements would be enforceable: 
for example, are there any grounds for eventually revoking improperly 
registered reassignments of IP space?

Routing is outside ARIN’s purview, so probably the best we can do there is 
document what kind of information is expected to be provided in an LOA, and how 
that interacts with any reassignment information published to ARIN. We might 
want to do something like require registration of the fact that space is 
reassigned, including things like start and expected end date of the 
reassignment, even if the identity of the assignee is kept confidential. That 
way anyone validating an LOA can at least verify that the space to be routed is 
reassigned to someone, and hasn’t been revoked. Or you could provide a 
public-key field in the public reassignment record, so that the LOA could 
include a private-key signature that allows for validation of its validity 
without having to publish the info it contains. (This starts to sound like a 
form of RPKI.)

Scott

> On May 30, 2019, at 7:01 AM, Mike Burns  wrote:
> 
> Hi Scott,
>  
> I would draft a policy in order to foster discussion, but I’m not sure I 
> would approve it myself yet.
> The concept would benefit from more discussion; it’s half-baked.
>  
> Can I 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: 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 
> records commonly done by ISPs for their customers.
> It should recognize that blocks can be legitimately advertised under 
> un-related ASNs with a valid Letter of Authorization, which must contain 
> certain information.
> It could have a process for identifying ARIN members who are participating in 
> a lease policy violation, for notifying them, and for potentially punishing 
> them under RSA terms.
>  
> I would support such a policy. Would you be interested in drafting it?
> 
> 
> Scott
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] IP leasing policy

[Scott Leibrand]

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 
> records commonly done by ISPs for their customers.
> It should recognize that blocks can be legitimately advertised under 
> un-related ASNs with a valid Letter of Authorization, which must contain 
> certain information.
> It could have a process for identifying ARIN members who are participating in 
> a lease policy violation, for notifying them, and for potentially punishing 
> them under RSA terms.

I would support such a policy. Would you be interested in drafting it?

Scott___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] IP leasing policy

[Scott Leibrand]

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.  Right now there is no policy,
> so leasing is allowed because it's not prohibited.
>
> No it doesn't. When someone leases IP addressing it proves it doesn't have
> use for its original justification. No one can think asking for more IP
> addressing and justify as "I need them to lease them" is something that
> would be ever accepted. If it is not a justification you can give to get
> more IPs from the RIR than it is not a accepted practice.
>
>
> ISPs lease space to their customers all the time, bundled with IP
> connectivity.  Hosting companies do the same.  So do VPN providers.  The
> challenge with a "no leasing allowed" policy is differentiating between a
> valid reassignment of space to accompany multihomed IP connectivity, vs. an
> invalid reassignment of space intended primarily as a lease, where any IP
> connectivity provided is incidental, or a fig leaf VPN that simply is set
> up to comply with the policy.
>
> That has nothing to do with the topic and is a totally different matter.
> It is conceptual. ISPs allocate IP address to their customers **which are
> not autonomous system** and cannot get them directly from the RIR.
>

That's not the only way IPs are allocated, reallocated, and assigned in the
RIR system.  It's also possible, and common, for an ISP to receive an
allocation from ARIN, and reallocate it to multihomed downstream customers
who do have their own ASN and are running BGP.  The ISP assigning the space
may be the primary provider of IP connectivity for the customer at the time
of the reallocation, but may not remain so.  Or they may be one of multiple
upstream transit providers, and just happen to be the one from whom it's
easiest/cheapest to get the needed IPv4 space.


> That's the main propose of an ISP Autonomous System go to the RIR to ask
> for IP space, to serve their internal needs and customers with Internet
> Services.
> When IP leases becomes the only service and **to another ASN** which
> inside the rules can ask directly to the RIR is certainly not the same
> thing as an ISP who allocates IP space to their end-user customer.
>

What if IP leases aren't the *only* service, but the IP space is bundled
with IP connectivity of some sort?  What kind of IP connectivity is
sufficient to make this "an ISP who allocates IP space to their end-user
customer" vs. an impermissible case of "IP leases becomes the only service"?

>
> A more tractable policy on leasing might focus on things like requiring
> registration of the downstream recipient of any leased space.  There may be
> other requirements that could be meaningfully enforced as well, but you'll
> need to be careful not to try to enforce requirements that impinge on the
> business of legitimate IP transit and hosting providers.
>
> That's not legitimate I'm sorry. It's not difficult to think things like:
> 1) Any Autonomous System should always go to the RIR and ask for more IP
> addresses
>

Such a policy would put most multihomed autonomous systems in violation of
your policy at some point in their growth.


> 2) If it has to go around it and get from another ASN there is something
> very wrong with it. Those addresses where given **to that ASN** for their
> internal use or end-user customers
>

The downstream ASN is their end-user customer.  That's why reallocations
exist, and not just reassignments.  But even reassignments are often made
to ASNs defined as end users (organizations not themselves acting as ISPs
and performing further reassignments).

3) If those addresses were given for this proposes and someone is not using
> (internal use or end-user who are not ASN) then that ASN doesn't justify
> for the IP space received anymore.
>

Such a policy would force the reclamation of a lot of legitimately in-use
space that is still in use primarily because it's difficult to renumber out
of.

Before going ahead and writing a more specific and clear policy for that
> need to find out how ARIN currently reads and apply that. Then think in a
> proper and well written policy to cover where else needed.
>
> I find very concerning defenses "as something pretty normal" use of IP
> address for proposes which they were never meant over the last decades, be
> a speculating and monetizing asset rather than serve to get people
> connected to the internet going against conversation and justification
> concepts. I see it seems the recent times of IPv4 exhaustion is making many
> to forget the very basics of Internet foundation and

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

[Scott Leibrand]

(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 with IP
connectivity.  Hosting companies do the same.  So do VPN providers.  The
challenge with a "no leasing allowed" policy is differentiating between a
valid reassignment of space to accompany multihomed IP connectivity, vs. an
invalid reassignment of space intended primarily as a lease, where any IP
connectivity provided is incidental, or a fig leaf VPN that simply is set
up to comply with the policy.

A more tractable policy on leasing might focus on things like requiring
registration of the downstream recipient of any leased space.  There may be
other requirements that could be meaningfully enforced as well, but you'll
need to be careful not to try to enforce requirements that impinge on the
business of legitimate IP transit and hosting providers.

If you'd like to take up the task of writing an enforceable policy on
(against?) leasing, I bet there are some people here on PPML, or possibly
even the AC, who'd be willing to work with you on that.

-Scott

On Wed, May 29, 2019 at 2:46 PM Fernando Frediani 
wrote:

> A lease policy should never exist in my opinion and registries should
> stand strong against it for the simple reason that IPs are not assets or
> something that belong to a company for it to lease.
>
> Is it always necessary to remind that IP addresses are meant to be used by
> the resource holders who  justified for that ? If someone is leasing it it
> obviously means it does not need and justify anymore for that IP space and
> any RIR should recover them immediately. If such a policy doesn't exist on
> its terms it should exist and should be discussed to make it sooner.
> I would recommend some Jon Postel reading to those who believe "it is Ok
> to lease IPs" as if they were they very own asset as a router or a server
> that you buy with a invoice and you do whatever you like with it.
>
> This type of thing goes pretty much against concepts of conservation and
> justification.
> Imagine if someone asked a RIR more IP address and may justify as "I need
> them in order to lease them". That's what a lease policy would walk towards
> to.
>
> As I mentioned in the other message, the fact the people do anyway and the
> whois doesn't get updated is **less important** than having people
> monetizing IP addresses in such way while there are others on waiting lists
> that truly justify for those addresses.
>
> Regards
> Fernando
> On 29/05/2019 18:02, Mike Burns wrote:
>
> Hi Robert,
>
>
>
> The problem of leasing space before the 12 month waiting period, so as *
> *only** to avoid that period, is small in my experience.
>
> After a year, any such lessor could sell if they wanted to, and they have
> the same sell/lease incentives as any other ARIN holder.
>
> Do you have evidence that people are monetizing waiting-list addresses
> prior to the 12 month period by leasing them?
>
>
>
> What you say below, however, is completely correct.
>
> I have tried to direct the community towards the glaring absence of a
> lease policy at any registry.
>
> I believe it’s time for such a policy, given the market circumstances we
> find ourselves in.
>
> Such a policy would allow for open leasing, with certain recording
> requirements for abuse contacts of the lessee, etc.
>
> I think such a policy would be in-scope and would yield, in a negative
> way, to the desired results of the anti-BGP hacking policy.
>
>
>
> Regards,
>
> Mike
>
>
>
>
>
>
>
>
>
> *From:* Robert Clarke  
> *Sent:* Wednesday, May 29, 2019 4:24 PM
> *To:* Mike Burns  
> *Cc:* Fernando Frediani  ;
> arin-ppml  
> *Subject:* Re: [arin-ppml] Waiting List IPv4 blocks transferred after
> issuance
>
>
>
> Hello Mike,
>
>
>
> Why are you using John's "waiting list IPv4 blocks transferred" numbers as
> a baseline for the /19 numbers? This is completely arbitrary and doesn't
> give any scale as to the problem with fraud. See my earlier reply to John's
> email in the other thread:
>
>
>
> "Thanks for sharing. I'd like to note that it can be dangerous to use the
> blocks transferred via 8.2/8.3/9.4 as a metric for abuse. A fraudster that
> gets past ARIN's scrutiny and obtains IPs with fraudulent information is
> probably smart enough to lease their IPs as opposed to selling the space
> outright. There is a huge market for leased space, and those deals happen
> behind closed doors with no oversight from ARIN. IP addresses go for
> $0.2-0.5/mo depending on term/IP reputation/size which could lead to
> $XX,XXX in illicit revenue with no risk of ARIN's scrutiny which would
> normally occur during the transfer process."
>
>
>
> Thanks,
>
>
>
> Robert Clarke
>
>
>
> On May 29, 2019, at 8:13 AM, Mike Burns  wrote:
>
>
>
> Hi Fernando,
>
>
>
> Thanks for the 

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

[Scott Leibrand]

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 IPs received from the waiting
> list should return to the waiting list in case of business cease, even if
> CORP-A swallow CORP-B assets, all allocations received from the waiting list
> should be annually reviewed and reentry on the waiting list should also be
> annually.
> 
> Sorry for my bad English.
> 
> Christian Lefrançois
> Diffusion Fermont
> 
> -Message d'origine-
> De : ARIN-PPML  De la part de
> arin-ppml-requ...@arin.net
> Envoyé : 24 mai 2019 13:56
> À : arin-ppml@arin.net
> Objet : ARIN-PPML Digest, Vol 167, Issue 153
> 
> Send ARIN-PPML mailing list submissions to
>arin-ppml@arin.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body '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 ARIN-PPML digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Revised - Advisory Council Recommendation Regarding NRPM
>  4.1.8. Unmet Requests (Leif Sawyer)
>   2. Re:  Revised - Advisory Council Recommendation RegardingNRPM
>  4.1.8. Unmet Requests (=?utf-8?B?SGF5ZWUgQm9raGFyaQ==?=)
>   3. Re: Revised - Advisory Council Recommendation Regarding NRPM
>  4.1.8. Unmet Requests (David Farmer)
> 
> 
> --
> 
> Message: 1
> Date: Fri, 24 May 2019 17:32:13 +
> From: Leif Sawyer 
> To: Michael Williams 
> Cc: "arin-ppml@arin.net" 
> Subject: Re: [arin-ppml] Revised - Advisory Council Recommendation
>Regarding NRPM 4.1.8. Unmet Requests
> Message-ID:
>
> Content-Type: text/plain; charset="windows-1252"
> 
> Michael, just to be clear:
> 
> You don't support the policy allowing for the transfer of IPs received by
> waitlist, for any reason?
> 
> Including the purchase and transfer of all assets by Corp-A  from Corp-B ,
> regardless of current utilization of the IPs?
> 
> --
> Leif Sawyer
> Enterprise Security Architect
> Enterprise Security Office
> GCI
> 
> 
> 
> From: ARIN-PPML [arin-ppml-boun...@arin.net] on behalf of Michael Williams
> [michael.willi...@glexia.com]
> Sent: Friday, May 24, 2019 9:18 AM
> To: ARIN
> Cc: arin-ppml@arin.net
> Subject: Re: [arin-ppml] Revised - Advisory Council Recommendation Regarding
> NRPM 4.1.8. Unmet Requests
> 
> [EXTERNAL EMAIL - CAUTION: Do not open unexpected attachments or links.]
> 
> Representing ARIN member organisation GLEXI-3, I disagree with the language
> of this policy proposal. Specifically:
> 
> 1) The maximum waitlist size should be a /21
> 2) The policy should require all IP allocations received from the waitlist
> be returned to ARIN if they are no longer used. IP allocations received via
> the waitlist should not be transferred, sold, or otherwise acquired in any
> other fashion.
> 
> Regards,
> 
> Michael Williams
> President/CEO Glexia, Inc
> 
> Sent from my iPhone
> 
>> On 25 May 2019, at 03:04, ARIN  wrote:
>> 
>> At their 16 May meeting, the Advisory Council revised their recommendation
> regarding NRPM 4.1.8. Unmet Requests.
>> 
>> The revised recommendation is hereby submitted to the Public Policy
> Mailing List for a second community discussion period of 14 days, to
> conclude on 7 June.
>> 
>> Once completed, the Board of Trustees will review the AC?s recommendation
> and the PPML discussion.
>> 
>> The full text of the Advisory Council's revised recommendation is below.
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> 
>> Advisory Council recommendation:
>> 
>> This is an updated version which incorporates feedback from the ARIN staff
> and was approved for further community consultation at the ARIN AC meeting
> on May 16, 2019.
>> 
>> In accordance with section 10.2 of the ARIN Policy Development Process,
> the ARIN Advisory Council recommends the following actions to the Board of
> Trustees in response to the Board?s suspension of part of the operation of
> sections 4.1.8, 4.1.8.1 and 4.1.8.2 of the
> Numbering Resource Policy Manual:
>> 
>> Replace section 4.1.8 et. seq. as follows, then reinstate the full
> operation of sections 4.1.8, 4.1.8.1 and
> 4.1.8.2 immediately.
>> 
>> 4.1.8 ARIN Waitlist
>> 
>> ARIN will only issue future IPv4 assignments/allocations (excluding 4.4
> and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an
> organization may qualify for at any one time is a /22. 

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

[Scott Leibrand]

If you were approved for a /21 and haven’t gotten it yet due to scarcity, I 
support giving you a /22 when it becomes available, and after 90 days letting 
you apply for another /22 and receive that if/when it becomes available. That 
way, you will get some space sooner (as the /21s in front of you will each only 
get a /22), and can either get the rest via transfer or by waiting further.

Scott

> On May 24, 2019, at 10:30 AM, Michael Williams  
> wrote:
> 
> Scott,
> 
> Would you support those us who are already on the waitlist for a /21?
> 
> Regards,
> 
> Michael
> 
> 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-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, Michael Williams 
>>>  wrote:
>>> 
>>> Representing ARIN member organisation GLEXI-3, I disagree with the
>>> language of this policy proposal. Specifically:
>>> 
>>> 1) The maximum waitlist size should be a /21
>>> 2) The policy should require all IP allocations received from the
>>> waitlist be returned to ARIN if they are no longer used. IP
>>> allocations received via the waitlist should not be transferred, sold,
>>> or otherwise acquired in any other fashion.
>>> 
>>> Regards,
>>> 
>>> Michael Williams
>>> President/CEO Glexia, Inc
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 25 May 2019, at 03:04, ARIN  wrote:
>>>> 
>>>> At their 16 May meeting, the Advisory Council revised their recommendation 
>>>> regarding NRPM 4.1.8. Unmet Requests.
>>>> 
>>>> The revised recommendation is hereby submitted to the Public Policy 
>>>> Mailing List for a second community discussion period of 14 days, to 
>>>> conclude on 7 June.
>>>> 
>>>> Once completed, the Board of Trustees will review the AC’s recommendation 
>>>> and the PPML discussion.
>>>> 
>>>> The full text of the Advisory Council's revised recommendation is below.
>>>> 
>>>> Sean Hopkins
>>>> Policy Analyst
>>>> American Registry for Internet Numbers (ARIN)
>>>> 
>>>> 
>>>> 
>>>> Advisory Council recommendation:
>>>> 
>>>> This is an updated version which incorporates feedback from the ARIN staff 
>>>> and was approved for further community consultation at the ARIN AC meeting 
>>>> on May 16, 2019.
>>>> 
>>>> In accordance with section 10.2 of the ARIN Policy Development Process, 
>>>> the ARIN Advisory Council recommends the following actions to the Board of 
>>>> Trustees in response to the Board’s suspension of part of the operation of 
>>>> sections 4.1.8, 4.1.8.1 and 4.1.8.2 of the Numbering Resource Policy 
>>>> Manual:
>>>> 
>>>> Replace section 4.1.8 et. seq. as follows, then reinstate the full 
>>>> operation of sections 4.1.8, 4.1.8.1 and 4.1.8.2 immediately.
>>>> 
>>>> 4.1.8 ARIN Waitlist
>>>> 
>>>> ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 
>>>> and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an 
>>>> organization may qualify for at any one time is a /22. Organizations will 
>>>> be able to elect a smaller block size than they qualify for down to a /24. 
>>>> Only organizations holding a /20 or less of IPv4 address space may apply 
>>>> and be approved. Address space distributed from the waitlist will not be 
>>>> eligible for transfer for a period of 60 months. This policy will be 
>>>> applied to all future distributions from the waitlist to include those 
>>>> currently listed.
>>>> 
>>>> Repeated requests, in a manner that would circumvent 4.1.6, are not 
>>>> allowed: an organization currently on the waitlist must wait 90 days after 
>>>> receiving a distribution from the waitlist before applying for additional 
>>>> space. ARIN, at its sole discretion, may waive this requirement if the 
>>>> requester can document a change in circumstances since their last request 
>>>> that could not have been reasonably foreseen a

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

[Scott Leibrand]

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, Michael Williams  
> wrote:
> 
> Representing ARIN member organisation GLEXI-3, I disagree with the
> language of this policy proposal. Specifically:
> 
> 1) The maximum waitlist size should be a /21
> 2) The policy should require all IP allocations received from the
> waitlist be returned to ARIN if they are no longer used. IP
> allocations received via the waitlist should not be transferred, sold,
> or otherwise acquired in any other fashion.
> 
> Regards,
> 
> Michael Williams
> President/CEO Glexia, Inc
> 
> Sent from my iPhone
> 
>> On 25 May 2019, at 03:04, ARIN  wrote:
>> 
>> At their 16 May meeting, the Advisory Council revised their recommendation 
>> regarding NRPM 4.1.8. Unmet Requests.
>> 
>> The revised recommendation is hereby submitted to the Public Policy Mailing 
>> List for a second community discussion period of 14 days, to conclude on 7 
>> June.
>> 
>> Once completed, the Board of Trustees will review the AC’s recommendation 
>> and the PPML discussion.
>> 
>> The full text of the Advisory Council's revised recommendation is below.
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> 
>> Advisory Council recommendation:
>> 
>> This is an updated version which incorporates feedback from the ARIN staff 
>> and was approved for further community consultation at the ARIN AC meeting 
>> on May 16, 2019.
>> 
>> In accordance with section 10.2 of the ARIN Policy Development Process, the 
>> ARIN Advisory Council recommends the following actions to the Board of 
>> Trustees in response to the Board’s suspension of part of the operation of 
>> sections 4.1.8, 4.1.8.1 and 4.1.8.2 of the Numbering Resource Policy Manual:
>> 
>> Replace section 4.1.8 et. seq. as follows, then reinstate the full operation 
>> of sections 4.1.8, 4.1.8.1 and 4.1.8.2 immediately.
>> 
>> 4.1.8 ARIN Waitlist
>> 
>> ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 
>> 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an 
>> organization may qualify for at any one time is a /22. Organizations will be 
>> able to elect a smaller block size than they qualify for down to a /24. Only 
>> organizations holding a /20 or less of IPv4 address space may apply and be 
>> approved. Address space distributed from the waitlist will not be eligible 
>> for transfer for a period of 60 months. This policy will be applied to all 
>> future distributions from the waitlist to include those currently listed.
>> 
>> Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: 
>> an organization currently on the waitlist must wait 90 days after receiving 
>> a distribution from the waitlist before applying for additional space. ARIN, 
>> at its sole discretion, may waive this requirement if the requester can 
>> document a change in circumstances since their last request that could not 
>> have been reasonably foreseen at the time of the original request, and which 
>> now justifies additional space. Qualified requesters whose request will also 
>> be advised of the availability of the transfer mechanism in section 8.3 as 
>> an alternative mechanism to obtain IPv4 addresses.
>> 
>> 4.1.8.1 Sequencing
>> 
>> The position of each qualified request on the waiting list will be 
>> determined by the date it was approved. Each organization may have one 
>> approved request on the waiting list at a time.
>> 
>> 4.1.8.2 Fulfillment
>> 
>> ARIN will fulfill requests on a first-approved basis, subject to the size of 
>> each available address block as address blocks become available for 
>> distribution. A timely review of the original request may be conducted by 
>> ARIN staff. Requests will not be partially filled. Any requests met through 
>> a transfer will be considered fulfilled and removed from the waiting list.
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN 

Re: [arin-ppml] Solving the squatting problem

[Scott Leibrand]

On May 16, 2019, at 9:07 PM, Michel Py  
wrote:.
> 
>> This isn’t a problem ARIN needs to solve.
> 
> Ok, I give up. Let's keep squatting.

Why don’t you just start squatting on 240/4 *without* RIR permission? This 
seems like an ideal case for permissionless innovation, as 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 network actually is.

You’re right, I should’ve said “one’s own network”, as I wasn’t referring to 
you (singular), but making a generalization. 

But now that you mention it: would it be easier to patch all your gear to 
support 240/4, or enable IPv6, for internal comms?

-Scott
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Solving the squatting problem

[Scott Leibrand]

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 along. And there 
is of course the whole “running code” thing: if a bunch of people start running 
code that lets them use 240/4 as private space, that might be better received 
than blue sky proposals to do so. 

That said, it’s not that difficult to use IPv6 inside your own network to 
replace RFC1918 space, so not sure if anyone would find the 240/4 effort 
worthwhile vs. just turning on IPv6 support in all the relevant places. 

Scott

On May 16, 2019, at 8:53 PM, Michel Py  
wrote:

>> Cathy Aronson wrote :
>> My point is that this has to come from the IETF
> 
> It does not. And failed attempts were 10 years ago, when almost everyone 
> still believed that IPv6 would be deployed "within 2 or 3 years".
> 
> I hate to break it to you, but ARIN members interest are not automatically 
> the same as the IETF, and it was more than 10 years ago.
> Since then, the world has ran out of IPv4 and it's still turning and the 
> Internet is still up.
> 
>> As Owen has said and the IETF has agreed, IPv6 is the “better alternative ”
> 
> It has been for 20 years, and still has not happened. Maybe 25% of the 
> Internet is dual-stacked, and maybe 3% is IPv6-only.
> 
> I rest my case.
> Michel.
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Of interest?

[Scott Leibrand]

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
validity of forgeries...

I expect that ARIN has considerably improved the rigor of their validations
since the first waitlist space was given out, and expect them to continue
doing so in the future.  I wouldn't expect them to discuss specifics of
their validation methods on a public mailing list, as they don't want to
inform potential scammers of what they'd need to do to bypass ARIN's checks.

We're probably better of getting back on topic and talking about what
number resource policy should be, not trying to reverse-engineer and
armchair-quarterback ARIN's procedures for implementing it.

-Scott

On Thu, May 16, 2019 at 12:40 PM Ronald F. Guilmette 
wrote:

>
> In message <98ea0db9-e347-40c6-a31e-362a07db9...@arin.net>,
> John Curran  wrote:
>
> >   I am not commenting on any particular matter, but note that ARIN
> has asked
> > for copies of government-issued identification in the past, and that is
> not
> >an assured protection mechanism (just as requiring notarized documents
> >cannot be 100% relied upon.)
>
> John,
>
> You made a clear and unambiguous assertion, i.e. that ARIN, as part
> of its vetting process, requires copies of personal identification
> documents.
>
> As I noted, the official and public legal filings, including transcripts
> of comments made in open court by ARIN's legal counsel, Steve Ryan,
> state that none of people who were represented, to ARIN, as being
> "officers" of these various ficitious entities... entities to which
> ARIN assigned several MILLION dollars worth of valuable property...
> ever actually existed.
>
> So I ask again, whose pictures were on the personal identification
> documents that you have claimed ARIN has been collecting, as part
> of its vetting?
>
> In lieu of a response, would it be wrong for unbaised observers to
> conclude that, contrary to your assertion, ARIN has -not- actually
> been either asking for or obtaining personal identification
> documents for any officers of any of the companies to which ARIN
> is routinely awarding great gobs of valuable property?
>
> It would be Nice to believe that ARIN *is* doing proper vetting of
> applicants, including but not limited to requiring copies of
> personal identification documents.  But the evidence at hand
> unambiguously suggests that this is not in fact the case, and that
> ARIN does and did assign lots of valuable property to phantoms.
>
> I may be alone in this view, but that is not my idea of "good
> stewardship".
>
>
> Regards,
> rfg
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Of interest?

[Scott Leibrand]

> 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 that the terms and conditions fo the RSA were 
> > effectively enforced by the arbitrator’s decision, including two specific 
> > basis for revocation: 1) RSA’s entered fraudulently may be considered as 
> > void (and resources revoked), and 2) in the alternative, to the extent that 
> > we consider the RSA a valid contract, then the fraudulent conduct is a 
> > breach the RSA (also permitting revocation.) 
> 
> 
> Hmm. That seems helpful. 
> 
> I'm less enthusiastic about another precedent that may have been set here - 
> that the scammer won't be required to make the community whole on the 
> resources that have already passed through his hands by the time the fraud is 
> halted. Unless that question is not yet settled?

Carefully parsing John’s statements, it appears that question will not be 
settled until the outcome of criminal proceedings is known, at which time ARIN 
will have the authority to revoke further address space if it can be shown that 
criminal activity put the scammer in breach of the RSA on any space he acquired 
directly and not through fraudulent representations. 

Let’s withhold judgement on what the scammer may have “gotten away with” until 
the wheels of justice have finished grinding. 

Scott___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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 the effect of giving a small number of space to the largest number of
organizations possible, which could be considered a feature or a bug
(increasing the number of routes that have to go into the global BGP table).

-Scott

On Mon, May 13, 2019 at 9:00 AM Jimmy Hess  wrote:

> On Mon, May 13, 2019 at 9:39 AM Tom Pruitt  wrote:
>
>
>> If those organizations were watching the list, and moving up, it is
>> likely that they have made
>>
> business decisions based on that data with the assumption that they would
>> get an allocation
>>
> at some point.   I believe the proposed allocation limit is being
>> discussed as a method to
>>
>
> Such speculations would not have been a very prudent to rely upon.
> Anyway: there is likely
> to not ever be a full /7,  so a /7 cannot be allocated, for example.  Some
> "natural" limit exists,
> whether exactly known or not,  and there's no guarantee of anyone on the
> list ever
> eventually getting filled.
>
> Perhaps it should simply be that when ordering the wait list ---  All
> requests whether new or
> still pending each XX day period,  say over 90 days will be considered
> simultaneously
> on one date,  and in addition to being ordered by request date,  the
> requests are sorted
> into buckets based on the number of total IP addresses requested, e.g.:
>
> All requests that can be satisfied at their minimum size by a /24, /23,
> /22, /21, or less (for example)
> in the entire waiting  list, and those larger being processed today shall
> each be sorted into a
> corresponding "bucket"   with other requests that can be satisfied at that
> size.
>
> All requests from every bucket of smaller sized requests shall be
> satisfied in at least their
> minimum size  before considering requests in any buckets of larger size.
>
>
> In this manner a "larger request" like a /20 could in theory be made,  but
> even if that request was pending for  2 years:   all the  new  requests
> that can be
> satisfied by /24 or less,  then /23 or less,  then /22 or less, then /21
> or less  should
> be considered and filled first.
>
> So to have any chance of filling a massive allocation,  then that should
> mean the
> waiting list has become essentially empty.
>
> --
> -JH
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

The IPv4 transfer market is perfectly legitimate: ARIN policy allows for the 
transfer of addresses to specified recipients who need them (like you) from 
organizations who can afford to renumber out of underutilized space if you pay 
them a market rate to do so. 

If your only objection to the transfer market is that you’d have to pay money 
(to avoid paying your upstreams), then I don’t think you have a valid objection 
to this policy proposal. Even under this proposal, you have a higher chance of 
getting a small block from ARIN, maybe even one that will meet your current 
needs, vs. the previous situation where everyone would hold out for /21s or 
larger that ARIN simply doesn’t have. And you can go acquire another /22 from 
the transfer market when you need it. 

If you really think that ARIN should be preferentially subsidizing your 
business model, you could propose a policy proposal attempting to define what 
IPv4-based business models are so beneficial to the Internet community that 
they should be funded by the entire ARIN community, not just their 
customers/members. But no such argument has been made (or is possible IMO) for 
“all entities that need fewer than 2048 but more than 1024 IPv4 addresses”. The 
closest we’ve come is for IPv6, where the subsidy is tiny by comparison: 
https://www.arin.net/participate/policy/nrpm/#6-5-9-community-network-allocations

Scott

> On May 12, 2019, at 8:55 AM, Christian Lefrançois 
>  wrote:
> 
> Hi all,
> I agree with Michael Williams, I'm in the same situation, and on the waiting
> list for more than a year. I need a /21, to finally be free of upstream
> providers fees for IPv4 addresses (lease). I'll gladly give back all
> resources to ARIN in the eventuality of end of business, or if I can manage
> to switch completely to IPv6. Not interested with the IPv4 black market.
> 
> I'm in charge of a very small coop cable operator, my market is about 1900
> customers, we're hooking members as fast as possible, will reach (and
> surpass) /22 in a few months. So, in my perspective, /21 should be the
> maximum.
> 
> Christian Lefrançois
> Diffusion Fermont
> 
> -Message d'origine-
> De : ARIN-PPML  De la part de
> arin-ppml-requ...@arin.net
> Envoyé : 10 mai 2019 18:33
> À : arin-ppml@arin.net
> Objet : ARIN-PPML Digest, Vol 167, Issue 80
> 
> Send ARIN-PPML mailing list submissions to
>arin-ppml@arin.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body '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 ARIN-PPML digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Fwd: Advisory Council Recommendation Regarding NRPM
>  4.1.8. Unmet Requests (Scott Leibrand)
> 
> 
> --
> 
> Message: 1
> Date: Fri, 10 May 2019 15:32:17 -0700
> From: Scott Leibrand 
> To: Michael Williams 
> Cc: Kevin Blumberg , "arin-ppml@arin.net"
>
> Subject: Re: [arin-ppml] Fwd: Advisory Council Recommendation
>Regarding NRPM 4.1.8. Unmet Requests
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
> 
> 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,
> the waitlist is intended to make sure that returned/reclaimed addresses are
> not stuck at ARIN, but rather distributed in a way that serves a useful
> purpose.
> 
> Organizations that need large blocks of address space should be going to the
> market to acquire them, and transferring them to meet their justified need.
> Some organizations that need smaller blocks of addresses, but not urgently,
> can try to get them via the waitlist.  But the more larger allocations we
> allow from reclaimed space, the fewer such organizations can be served, and
> the longer they'll need to wait.  So it makes sense to me to have a
> relatively stringent maximum wait list allocation, particularly since that
> also reduces the financial reward to fraudulent actors and/or those
> attempting to game the system.
> 
> So I support this policy, including the /22 maximum.
> 
> -Scott (representing only myself)
> 
> On Fri, May 10, 2019 at 3:19 PM Michael Williams <
> michael.willi...@glexia.com> wrote:
> 
>> Repre

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

[Scott Leibrand]

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 implied threat, will be any more effective
> than current methods of
> > shutting down hijacks once they've started?  My impression is that
> nearly all hijacks are quickly filtered by transit providers once they're
> contacted by the legitimate holder of the addresses.
>
> Hi,
>
> However, some hijackers decide to use unallocated space or space which is
> likely to be held by closed companies -- so a contact by the legitimate
> owner becomes highly unlikely.
>

In that case, who is the party who is harmed by someone announcing
unallocated or unannounced space?


> > IMO "punishment" of those responsible for allowing hijacking seems like
> something best solved through the legal system, not via extrajudicial
> penalties and fines imposed by an industry association.  But if we do
> decide we want ARIN
> > to create acceptable standards of conduct with regard to routing, and
> fine resource holders who violate it, under threat of resource revocation
> if those fines aren't paid, there will need to be a *lot* of work done to
> set up such a
> > system so that it doesn't risk ARIN picking a legal fight it's going to
> lose, and putting the entire registry at risk.
>
> I don't really see how the registry is more at risk when the data it
> contains is made irrelevant by some of its members...
>

If ARIN overreaches in their attempt to penalize a large non-cooperative
well-lawyered transit provider for not filtering their customers well
enough by revoking their registrations, and that transit provider sues ARIN
for interfering with its business, it's likely that ARIN would lose a
lawsuit and either lose control over the registry and/or have to pay
damages that might bankrupt the organization.  Those are the kinds of legal
concerns that will prevent ARIN from doing something that the community
might otherwise want.


> About the legal system:
> - In how many countries in the ARIN region it is against the law to hijack
> internet prefixes?
> - In how many states within the US is against the law to hijack internet
> prefixes?
>
> I actually don't have an answer for any of those two questions above, so
> if anyone has a clue, it will be most appreciated! :-)
>
> If the answer is "zero" to both... then the legal system is not really an
> option. :/
>

Even if there isn't a law explicitly disallowing BGP hijacking (I don't
know if/where there is), the legal system is still an option for going
after bad actors.  IANAL, but if nothing else, you can sue them in civil
courts for the damages caused by tortious interference with your business,
or whatever the proper legal term is for that.  In the US, you can always
sue someone.  ;-)

-Scott



> > On Thu, May 2, 2019 at 1:29 PM Andrew Bagrin  wrote:
> >   If the hijacking entity is not and ARIN customer, ARIN likely has
> a relationship with adjacent ASN's that propagate the hijacked BGP routes
> and can at the very least notify them that they are propagating routes that
> have
> >   been reported as being hijacked. They can further repeat the
> statement with a firm voice, and add "or else" at the end.
> >
> > Add penalties and fines could be a way to reduce prolonged propagation
> of hijacked routes.
> >
> >
> >
> > On Thu, May 2, 2019 at 10:18 AM Adam Thompson 
> wrote:
> >
> >   Instead of focusing on whether the current proposal is or isn?t in
> scope, I suggest we re-cast the discussion as follows:
> >
> >
> >
> >1. So far, we have unanimous community agreement that BGP
> hijacking is bad.
> >2. So far, we have broad agreement that ?something ought to be
> done? about BGP hijacking, although detailed opinions vary significantly.
> >3. So what (else) can ARIN do about it?  (Caveat: the answer
> ?nothing? is unacceptable to a significant proportion of PPML participants.)
> >
> >
> >
> >   My suggested direction to the AC and/or the board would therefore
> be:  Find something ARIN can do to help combat the problem (more
> effectively).  If this requires expanding the scope of ARIN?s operations or
> policies,
> >   bring that back to the membership (possibly via PPML?) with the
> accompanying financial & legal analysis, as usual.
> >
> >
> >
> >   Now the question becomes: what is the most appropriate mechanism,
> within ARIN?s existing policies, to bring a request like that to

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

[Scott Leibrand]

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
that nearly all hijacks are quickly filtered by transit providers once
they're contacted by the legitimate holder of the addresses.

IMO "punishment" of those responsible for allowing hijacking seems like
something best solved through the legal system, not via extrajudicial
penalties and fines imposed by an industry association.  But if we do
decide we want ARIN to create acceptable standards of conduct with regard
to routing, and fine resource holders who violate it, under threat of
resource revocation if those fines aren't paid, there will need to be a
*lot* of work done to set up such a system so that it doesn't risk ARIN
picking a legal fight it's going to lose, and putting the entire registry
at risk.

-Scott

On Thu, May 2, 2019 at 1:29 PM Andrew Bagrin  wrote:

> If the hijacking entity is not and ARIN customer, ARIN likely has a
> relationship with adjacent ASN's that propagate the hijacked BGP routes and
> can at the very least notify them that they are propagating routes that
> have been reported as being hijacked.
> They can further repeat the statement with a firm voice, and add "or else"
> at the end.
>
> Add penalties and fines could be a way to reduce prolonged propagation of
> hijacked routes.
>
>
>
> On Thu, May 2, 2019 at 10:18 AM Adam Thompson 
> wrote:
>
>> Instead of focusing on whether the current proposal is or isn’t in scope,
>> I suggest we re-cast the discussion as follows:
>>
>>
>>
>>1. So far, we have unanimous community agreement that BGP hijacking
>>is bad.
>>2. So far, we have broad agreement that “something ought to be done”
>>about BGP hijacking, although detailed opinions vary significantly.
>>3. So what (else) *can* ARIN do about it?  (Caveat: the answer “
>>*nothing*” is unacceptable to a significant proportion of PPML
>>participants.)
>>
>>
>>
>> My suggested direction to the AC and/or the board would therefore be:
>> *Find* something ARIN can do to help combat the problem (more
>> effectively).  If this requires expanding the scope of ARIN’s operations or
>> policies, bring that back to the membership (possibly via PPML?) with the
>> accompanying financial & legal analysis, as usual.
>>
>>
>>
>> Now the question becomes: what is the most appropriate mechanism, within
>> ARIN’s existing policies, to bring a request like that to the AC and/or
>> Board?  It seems clear to me that the petition already underway here is not
>> meeting, and will not meet, the needs of the community very well.
>>
>>
>>
>> -Adam
>>
>>
>>
>> *Adam Thompson*
>> Consultant, Infrastructure Services
>> *[image: merlin-email-logo]*
>> 100 - 135 Innovation Drive
>> Winnipeg, MB, R3T 6A8
>> (204) 977-6824 or 1-800-430-6404 (MB only)
>> athomp...@merlin.mb.ca
>> www.merlin.mb.ca
>>
>>
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

> 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 
>> threaten to revoke unrelated registrations from a transit provider who 
>> willfully or negligently accepted the BGP announcement of space from an 
>> entity it wasn’t registered to. But if tier 1 transit providers aren’t 
>> willing to filter, let alone depeer, each other over hijacking today, it 
>> seems unlikely they’d be willing to stop accepting formerly legitimate 
>> prefixes from a peer or customer network just because ARIN is trying to take 
>> that space away to punish the network for accepting an unrelated hijacked 
>> announcement. 
> 
> It doesn't really seem to be this the discussion about Transit providers 
> accepting or not certain announcements. Even if a Transit Provider accepts 
> announcements from people who are not responsible for an allocation nor has 
> authorization to do that they should only be warned to take correction 
> measures. I don't think the main aim of the propose is do anything with 
> Transit providers.
> Even in a hypothesis a Transit provider has no filters a hijack will not 
> occur if a hijacker doesn't initiate it.

If the hijacker is someone with no relationship with ARIN, we can’t punish them 
by kicking them out of a club they’re not a member of. If you’re ok with ARIN 
doing nothing about hijacks by entities who don’t have ARIN resources, fine: 
that’s the status quo. But if you do want ARIN to do something on those cases 
(which I believe are the vast majority of hijacks) the only action I can see 
that ARIN could take at that point is against whichever of their transit 
providers is accepting the hijacked routes. 

-Scott

>> 
>> On May 2, 2019, at 7:18 AM, Adam Thompson  wrote:
>> 
>>> Instead of focusing on whether the current proposal is or isn’t in scope, I 
>>> suggest we re-cast the discussion as follows:
>>>  
>>> So far, we have unanimous community agreement that BGP hijacking is bad.
>>> So far, we have broad agreement that “something ought to be done” about BGP 
>>> hijacking, although detailed opinions vary significantly.
>>> So what (else) can ARIN do about it?  (Caveat: the answer “nothing” is 
>>> unacceptable to a significant proportion of PPML participants.)
>>>  
>>> My suggested direction to the AC and/or the board would therefore be:  Find 
>>> something ARIN can do to help combat the problem (more effectively).  If 
>>> this requires expanding the scope of ARIN’s operations or policies, bring 
>>> that back to the membership (possibly via PPML?) with the accompanying 
>>> financial & legal analysis, as usual.
>>>  
>>> Now the question becomes: what is the most appropriate mechanism, within 
>>> ARIN’s existing policies, to bring a request like that to the AC and/or 
>>> Board?  It seems clear to me that the petition already underway here is not 
>>> meeting, and will not meet, the needs of the community very well.
>>>  
>>> -Adam
>>>  
>>> Adam Thompson
>>> Consultant, Infrastructure Services
>>> 
>>> 100 - 135 Innovation Drive
>>> Winnipeg, MB, R3T 6A8
>>> (204) 977-6824 or 1-800-430-6404 (MB only)
>>> athomp...@merlin.mb.ca
>>> www.merlin.mb.ca
>>>  
>>> ___
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@arin.net if you experience any issues.
>> 
>> 
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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 
RIR?

Or 2) is nearly all hijacking being performed by entities that have no 
relationship with the RIR?

If 1) is true, then ARIN could theoretically revoke an organization’s 
registrations if they used address space that was not registered to them. We 
can of course debate whether we want RIRs to serve as adjudicators of what 
space RIR members are allowed to announce, but there would at least be 
something RIRs could do (kick non-cooperators out of the club of RIR 
registrants) to enforce their decisions if they decided to make them. 

But if 1) is false and 2) is true, then it’s not clear what ARIN could do about 
a case of BGP hijacking by someone who doesn’t have any ARIN resources 
registered to them. Can you think of anything we’d actually want ARIN to do in 
that case?

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 threaten to revoke 
unrelated registrations from a transit provider who willfully or negligently 
accepted the BGP announcement of space from an entity it wasn’t registered to. 
But if tier 1 transit providers aren’t willing to filter, let alone depeer, 
each other over hijacking today, it seems unlikely they’d be willing to stop 
accepting formerly legitimate prefixes from a peer or customer network just 
because ARIN is trying to take that space away to punish the network for 
accepting an unrelated hijacked announcement. 

Scott

> On May 2, 2019, at 7:18 AM, Adam Thompson  wrote:
> 
> Instead of focusing on whether the current proposal is or isn’t in scope, I 
> suggest we re-cast the discussion as follows:
>  
> So far, we have unanimous community agreement that BGP hijacking is bad.
> So far, we have broad agreement that “something ought to be done” about BGP 
> hijacking, although detailed opinions vary significantly.
> So what (else) can ARIN do about it?  (Caveat: the answer “nothing” is 
> unacceptable to a significant proportion of PPML participants.)
>  
> My suggested direction to the AC and/or the board would therefore be:  Find 
> something ARIN can do to help combat the problem (more effectively).  If this 
> requires expanding the scope of ARIN’s operations or policies, bring that 
> back to the membership (possibly via PPML?) with the accompanying financial & 
> legal analysis, as usual.
>  
> Now the question becomes: what is the most appropriate mechanism, within 
> ARIN’s existing policies, to bring a request like that to the AC and/or 
> Board?  It seems clear to me that the petition already underway here is not 
> meeting, and will not meet, the needs of the community very well.
>  
> -Adam
>  
> Adam Thompson
> Consultant, Infrastructure Services
> 
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>  
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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.  Receipt of a smaller block
via the waiting list should probably reduce the size of the remaining
approved transfer request, but it might also be good to revisit that at the
time of waitlist issuance to see what their current needs are...

-Scott

On Thu, Mar 7, 2019 at 11:57 AM John Curran  wrote:

> On 7 Mar 2019, at 10:32 AM, Tom Fantacone  wrote:
>
>
> Andrew, am I right in assuming that ARIN is under no obligation to follow
> the current policy for organizations on the waiting list if this new policy
> is implemented?  When they joined the waiting list, they understood the
> policy at the time, but was it with the further understanding that ARIN
> could change the policy?
>
>
> ARIN is under no obligation to follow the previous policy for those
> already on the wait list; issuance of number resources is always done per
> current policy.
>
> Ideally, the community would specify what transition is appropriate for
> those presently on the waiting list; absent such, there will be a staff and
> legal review pointing out the omission and staff will note its default
> approach so that implementation can still proceed should the policy change
> be adopted as-is.
>
> Thanks,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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 should be 
getting it from the transfer market anyway, so I don’t see much downside to 
such a restriction on waiting list allocations. 

Scott

> On Feb 26, 2019, at 9:49 AM, ARIN  wrote:
> 
> On 21 February 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-261: 
> Waiting List Block Size Restriction" as a Draft Policy.
> 
> Draft Policy ARIN-2019-2 is below and can be found at:
> https://www.arin.net/policy/proposals/2019_2.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-2019-2: Waiting List Block Size Restriction
> 
> Problem Statement:
> 
> A substantial amount of misuse of the waiting list is suspected by ARIN 
> staff. A significant percentage of organizations that receive blocks from the 
> waiting list subsequently issue these blocks to other organizations via 8.3 
> or 8.4 transfers shortly after the one year waiting period required before 
> engaging in such outbound transfers. Most of these cases involve larger-sized 
> blocks, and many involve organizations that already have large IPv4 holdings. 
> Some organizations engage in this practice multiple times, rejoining the 
> waiting list shortly after transferring out blocks previously received on the 
> waiting list. There are even cases of multiple startup organizations 
> requesting approval to be placed on the waiting list where these 
> organizations' requests can all be tracked originating from the same IP 
> address. While it is possible that some of these cases are legitimate, and 
> while it is difficult for ARIN to prove fraud in most individual cases, the 
> large number of cases like these indicates a high likelihood that there is 
> significant misuse of the waiting list. Specifically, some organizations are 
> likely being dishonest in projecting their need for IPv4 space with the 
> intent of receiving blocks off the waiting list so that they can sell them 
> one year after receiving them. In the case of multiple startups, some 
> organizations that receive blocks on the waiting list subsequently perform a 
> 8.2 merger/acquisition, allowing them to sell the blocks even before the one 
> year waiting period.
> 
> The problem is serious enough that the ARIN Board of Trustees has suspended 
> issuance of number resources while a solution to this problem is found, and 
> it is unfair to organizations with legitimate need on the waiting list that 
> they are being crowded out and delayed by those looking to game the system.
> 
> Policy Statement:
> 
> Actual Text:
> 
> 4.1.8. Unmet requests
> 
> In the event that ARIN does not have a contiguous block of addresses of 
> sufficient size to fulfill a qualified request, ARIN will provide the 
> requesting organization with the option to specify the smallest block size 
> they'd be willing to accept, equal to or larger than the applicable minimum 
> size specified elsewhere in ARIN policy. If such a smaller block is 
> available, ARIN will fulfill the request with the largest single block 
> available that fulfills the request. If no such block is available, the 
> organization will be provided the option to be placed on a waiting list of 
> pre-qualified recipients, listing both the block size qualified for and the 
> smallest block size acceptable.
> 
> New Text:
> 
> 4.1.8. Unmet requests
> 
> In the event that ARIN does not have a contiguous block of addresses of 
> sufficient size to fulfill a qualified request, ARIN will provide the 
> requesting organization with the option to specify the smallest block size 
> they'd be willing to accept, equal to or larger than the applicable minimum 
> size specified elsewhere in ARIN policy. If such a smaller block is 
> available, ARIN will fulfill the request with the largest single block 
> available that fulfills the request. If no such block is available, the 
> organization will be provided the option to be placed on a waiting list of 
> pre-qualified recipients, listing both the block size qualified for or a /22, 
> whichever is smaller, and the 

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

[Scott Leibrand]

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 Tom - responses inline.
> 
> One additional point - the current policy places a limit on how often an 
> organization can receive resources from the waiting list. This draft changes 
> the hold-down timer so that it now applies to *applications* for new 
> allocations under the waiting list policy, not the receipt of resources from 
> it.
> 
>> On Mar 3, 2019, at 7:18 AM, Tom Fantacone  wrote:
>> 
>> Chris,
>> 
>> The "clarification" part of your proposal seems to be a no brainer (the 
>> waiting period is meant to apply to allocations only under section 4).  I 
>> assume ARIN staff is already interpreting it this way since that was the 
>> intent of the section.  So I wouldn't sever it unless the full policy 
>> doesn't gain support in which case we could revisit just inserting the 
>> clarification part.
>> 
> 
> That assumption is my understanding as well.
> 
>> Regarding this:
>> "- Disallows organizations that have transferred space to other parties 
>> within the past 12 months from applying for additional IPv4 space under NRPM 
>> Section 4. "
>> 
>> I want to make sure I understand it correctly.  If you transfer out space 
>> via 8.2/8.3/8.4, does this restriction mean you just can't receive space via 
>> the waiting list for 12 months, or via any mechanism (waiting list/transfer) 
>> for 12 months?  I think it means from the waiting list only, but want to be 
>> sure.
>> 
> 
> That is correct - note the phrase “...under this section...” in the proposal 
> text. 
> 
> Thanks,
> 
> -Chris
> 
> 
>> Tom
>> 
>> 
>> 
>>  On Sat, 02 Mar 2019 13:48:01 -0500 Chris Woodfield 
>>  wrote 
>> 
>> Speaking as the policy author, I’ll make two points:
>> 
>> 1. I’m aware that given the other discussions around waiting list policy 
>> that are ongoing, this proposal may well be rendered moot by future policy 
>> changes. I still believe that this is worth pursuing as there’s a current 
>> need for clarification and increased disincentives for bad behavior today.
>> 2. I’m deliberately killing two not-terribly-related birds with one stone 
>> with this proposal, based on the fact that the two issues noted from the PER 
>> can be addressed by adding language to the same NRPM text. Happy to consider 
>> severing them if the community prefers.
>> 
>> Thanks,
>> 
>> -Chris
>> 
>>> On Mar 2, 2019, at 9:33 AM, hostmas...@uneedus.com wrote:
>>> 
>>> I think it is time to start the ball on the other policies.
>>> 
>>> +1 on this. It seems focused on those gathering resources to resell.
>>> 
>>> Albert Erdmann
>>> Network Administrator
>>> Paradise On Line Inc.
>> t i...@arin.net if you experience any issues.
>> 
>> 
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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, 2018 at 12:53 PM ARIN  wrote:

> On 15 November 2018 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-257: Disallow Third-party Organization Record Creation" as a
> Draft Policy.
>
> Draft Policy ARIN-2018-5 is below and can be found at:
> https://www.arin.net/policy/proposals/2018_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-2018-5: Disallow Third-party Organization Record Creation
>
> Problem Statement:
>
> Since the introduction of simple-reassignment some years ago, it is no
> longer necessary to allow for third-parties (such as upstream ISPs) to
> create organization records for another entity (such as their
> customers).  In particular, many entities find that spurious
> organization records are routinely created in their name, causing both
> confusion and entity + staff time for clean-up.
>
> Therefore, this policy establishes that organization records shall be
> created only by the entity represented by the organization record, and
> should be created only through an explicit request to ARIN.  ISPs
> wishing to reassign space to customers should either ask the customer
> for their ORG-ID or shall use the "simple reassignment" method which
> does not require nor create new organization records.  ISPs wishing to
> reallocate space to customers should ask the customer for their ORG-ID.
>
> Policy Statement:
>
> Add new sections into the NRPM:
>
> 3.7 Organization and Resource Records
>
> 3.7.1 Organizations
>
> ARIN shall track and publish a database of organizations which have
> registered with ARIN or have, in the past, received resources from ARIN
> or a predecessor registry.  New organization records shall be created
> upon ARIN receiving a request directly from an authorized contact
> representing an entity that ARIN is able to validate.  Organization
> records shall not be created upon the request of third-parties or by a
> side-effect of other registration activity, including but not limited to
> reassignment and reallocation.
>
> 3.7.2 Resources
>
> ARIN shall track and publish a database of resources which have been
> issued by ARIN or a predecessor registry to entities.  Resources so
> issued may, as permitted by other sections of this policy manual, be
> further sub-delegated to other entities.  Such sub-delegations shall be
> tracked in the ARIN database as specified in this section, or shall be
> published as specified in section 3.2.
>
> 3.7.2.1 Direct Allocations and Assignments
>
> Direct allocations and direct assignments of resources from ARIN to an
> entity shall be reflected in the database and shall list the registered
> organization (previously created, by the entity, pursuant to section
> 3.7.1) to which those resources are allocated or assigned.
>
> 3.7.2.2 Reallocations and Reassignments
>
> Except as permitted by sections 3.2 or 3.7.2.3, ISPs which are required
> to publish reallocations and reassignments to customers shall do so by
> entering records into the ARIN database listing the registered
> organization (previously created, by the customer, pursuant to section
> 3.7.1) to which those resources are reallocated or reassigned.
>
> 3.7.2.3 Simple Reassignments
>
> ISPs which are required to publish reassignments to customers may elect
> to use the "simple reassignment" method in lieu of the other methods as
> specified in section 3.2 or 3.7.2.2.  The simple reassignment method
> does not require the customer entity to have registered as an
> organization with ARIN.  Instead, the ISP may furnish to ARIN a limited
> set of customer information (such as the entity name and address) along
> with the IP address range or prefix to be delegated.  ARIN shall create
> a limited-purpose "customer" record for such entities in lieu of full
> organization records as specified in section 3.7.1.  These customer
> records shall be clearly distinguishable in the ARIN database.
>
> Comments:
>
> Timetable for implementation: Immediate
> ___
> ARIN-PPML
> You are 

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

[Scott Leibrand]

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 onto your new one, resulting in a longer AS path over that session.
Both outcomes are disruptive to a network's ability to maintain peering.

Given that there are valid technical and business justifications for
needing to keep the same ASN on a network whose locus of control switches
continents, I believe it is appropriate to allow organizations who need to
do so to transfer administrative control of their ASN between RIRs, and
therefore support this draft policy.

While it is certainly possible for some networks to easily renumber their
ASN, that is not true of all networks, for valid technical reasons.  I
therefore do not find arguments of the "I've never needed to do that" or "I
can't imagine why someone would need to do that" informative or
convincing.  To my mind, the only argument that would justify opposing ASN
transfers would be one that details how such transfers would be burdensome
to the RIRs or to the Internet community more generally, and would further
show that such burden is greater than the benefit to those organizations it
would help.  As I, Job, and others have detailed the kind of organization
that would be benefited by this proposal, it's not sufficient to assert
that such organization do not (or should not) exist.

-Scott

On Mon, Aug 13, 2018 at 3:36 PM Job Snijders  wrote:

> On Tue, 14 Aug 2018 at 01:23, Larry Ash  wrote:
>
>> On Mon, 13 Aug 2018 14:47:09 -0700
>>   Owen DeLong  wrote:
>> >> On Aug 13, 2018, at 14:42 , Job Snijders  wrote:
>> >>
>> >> I agree with the proposal.
>> >>
>> >> I think this proposal is needed and addresses practical concerns: the
>> alternative to transfers is “renumbering”, and renumbering
>> >>ASNs is a very costly and operationally risky proposition. There is no
>> upside to restricting or forbidding this type of resource
>> >>transfer.
>> >>
>> >> A question that remains: if you don’t want to transfer your ASN in or
>> out of ARIN, then don’t, but why forbid others from doing
>> >>it? All resources should be transferable.
>> >
>> > We can agree to disagree.
>>
>> I agree with Owen, I just can't see a burning need. Renumbering seems to
>> be a bugaboo that is just not that difficult.
>
>
> Even if you don’t see a need, would you want to preclude others from
> transferring their resource if they concluded it is a requirement for their
> business operation?
>
>
> I would think the transfer of the ASN would as costly, difficult and risky
>> as migrating the resources onto a new ASN.
>
>
>
> I’m puzzled by your statement. Renumbering an ASN may involve operations
> on hundreds of routers and tens of thousands of BGP sessions - such
> renumbering clearly is costly and operationally risky.
>
> Transferring a resource from one RIR to another RIR is paperwork between
> RIRs - no router changes. A transfer and a renumbering don’t seem
> comparable at all. Do you consider IPv4 transfers costly and risky too?
>
> Kind regards,
>
> Job
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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​
> ​
>
> On Mon, Mar 12, 2018 at 5:47 PM, Christian Tacit 
> wrote:
>
>> Dear Community Members,
>>
>>
>>
>> The shepherds for the Draft Policy 2017-12: Require POC Validation Upon
>> Reassignment, are making two changes to its text.
>>
>>
>>
>> First, the problem statement is being expanded a bit to explain how POCs
>> for reassigned blocks can be assigned without the knowledge of the
>> individuals so assigned under the present policy.
>>
>>
>>
>> Second, proposed section 3.8 has been deleted. This is because it is
>> unintentionally misleading because a simple reassignment results in a
>> customer identifier versus an OrgID.   There is no contact information
>> contained in a simple reassignment other than street address that could be
>> used for notification, and thus it does not appear that the proposed NRPM
>> 3.8 policy text is implementable.  Even if notification were possible, the
>> “OR postal address” in this section may also cause significant problems for
>> some companies as many companies have the same name associated with many
>> different locations and there are several locations that have many
>> companies registered there.
>>
>>
>>
>> Based on these changes, the revised text reads:
>>
>>
>>
>> *Version Date: March 12, 2018*
>>
>>
>>
>> *Problem Statement:*
>>
>> Some large ISPs assign individuals to be POCs for reassigned blocks
>> without consultation of the individual they are inserting into Whois. For
>> example, during the reassignment/reallocation process, some large ISPs
>> automatically create POCs from their customer’s order form. This process is
>> automated for many ISPs and therefore the resulting POCs are not validated
>> prior to being created in the ARIN Whois database. This creates unknowing
>> POCs that have no idea what Whois is or even who ARIN is at the time they
>> receive the annual POC validation email. It can also create multiple POCs
>> per email address causing that same person to receive a multitude of POC
>> Validation emails each year.
>>
>> This policy proposal seeks to improve the situation where a POC is
>> unwittingly and unintentionally inserted into Whois.
>>
>> It also seeks to mitigate the significant amount of time that ARIN staff
>> reports that they spend fielding phone calls from POCs who have no idea
>> they are in Whois.
>>
>> Finally, it is hopeful that this proposal will improve the overall POC
>> validation situation, by forcing ISPs and customers to work together to
>> insert proper information into Whois at the time of sub-delegation.
>>
>>
>>
>> *Policy statement:*
>>
>> Insert one new section into NRPM 3:
>>
>> 3.7 New POC Validation Upon Reassignment
>>
>> When an ISP submits a valid reallocation or detailed reassignment request
>> to ARIN which would result in a new POC object being created, ARIN must
>> (before otherwise approving the request) contact the new POC by email for
>> validation. ARIN's notification will, at a minimum, notify the POC of:
>>
>> - the information about the organization submitting the record; and
>> - the resource(s) to which the POC is being attached; and
>> - the organization(s) to which the POC is being attached.
>>
>> If the POC validates the request, the request shall be accepted by ARIN
>> and the new objects inserted into Whois.  If the POC does not validate the
>> request within 10 days, ARIN must reject the request.
>>
>>
>>
>> *Timetable for implementation:* Immediate
>>
>>
>>
>> Comments from the community are welcome!
>>
>>
>>
>>
>> Christian S. Tacit
>>
>>
>>
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@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@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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 the new POC to replace the proposed new POC
object with a reference to one of their existing POC records...

-Scott

On Tue, Mar 13, 2018 at 11:07 AM,  wrote:

> I support.
>
> I think this will go a long way in getting correct POC's in the database
> at the start.  Currently, whoever is doing the ordering might end up with
> their contacts in the database, because that is the only information that
> the service provider has. This is how we end up with purchasing or
> accounting contacts in Whois who have no clue as to abuse complaints and/or
> the annual validation email.  This will force the service provider to
> actually ASK who the company wants as a Whois contact, and to explain to
> them what duties this involves, including a reminder of the annual
> validation email that they need to respond to.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
> On Mon, 12 Mar 2018, Christian Tacit wrote:
>
> Dear Community Members,
>>
>> The shepherds for the Draft Policy 2017-12: Require POC Validation Upon
>> Reassignment, are making two changes to its text.
>>
>> First, the problem statement is being expanded a bit to explain how POCs
>> for reassigned blocks can be assigned without the knowledge of the
>> individuals so assigned under the present policy.
>>
>> Second, proposed section 3.8 has been deleted. This is because it is
>> unintentionally misleading because a simple reassignment results in a
>> customer identifier versus an OrgID.  There is no contact information
>> contained in a simple reassignment other than street address that could be
>> used for notification, and thus it does not appear that the proposed NRPM
>> 3.8 policy text is implementable.  Even if notification were possible, the
>> "OR postal address" in this section may also cause significant problems for
>> some companies as many companies have the same name associated with many
>> different locations and there are several locations that have many
>> companies registered there.
>>
>> Based on these changes, the revised text reads:
>>
>>
>> Version Date: March 12, 2018
>>
>>
>>
>> Problem Statement:
>>
>> Some large ISPs assign individuals to be POCs for reassigned blocks
>> without consultation of the individual they are inserting into Whois. For
>> example, during the reassignment/reallocation process, some large ISPs
>> automatically create POCs from their customer's order form. This process is
>> automated for many ISPs and therefore the resulting POCs are not validated
>> prior to being created in the ARIN Whois database. This creates unknowing
>> POCs that have no idea what Whois is or even who ARIN is at the time they
>> receive the annual POC validation email. It can also create multiple POCs
>> per email address causing that same person to receive a multitude of POC
>> Validation emails each year.
>>
>> This policy proposal seeks to improve the situation where a POC is
>> unwittingly and unintentionally inserted into Whois.
>>
>> It also seeks to mitigate the significant amount of time that ARIN staff
>> reports that they spend fielding phone calls from POCs who have no idea
>> they are in Whois.
>>
>> Finally, it is hopeful that this proposal will improve the overall POC
>> validation situation, by forcing ISPs and customers to work together to
>> insert proper information into Whois at the time of sub-delegation.
>>
>>
>>
>> Policy statement:
>>
>> Insert one new section into NRPM 3:
>>
>> 3.7 New POC Validation Upon Reassignment
>>
>> When an ISP submits a valid reallocation or detailed reassignment request
>> to ARIN which would result in a new POC object being created, ARIN must
>> (before otherwise approving the request) contact the new POC by email for
>> validation. ARIN's notification will, at a minimum, notify the POC of:
>>
>> - the information about the organization submitting the record; and
>> - the resource(s) to which the POC is being attached; and
>> - the organization(s) to which the POC is being attached.
>>
>> If the POC validates the request, the request shall be accepted by ARIN
>> and the new objects inserted into Whois.  If the POC does not validate the
>> request within 10 days, ARIN must reject the request.
>>
>>
>>
>> Timetable for implementation: Immediate
>>
>> Comments from the community are welcome!
>>
>>
>> Christian S. Tacit
>>
>>
>>
>> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you 

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

[Scott Leibrand]

> 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 company decides to buy another company with few assets, but holds a 16 
> bit ASN in another RIR region.  They then want to bring that ASN back to ARIN 
> so they can add it to their registration plan.  This is similar to M of 
> companies with IPv4 addresses as assets, since they can not get a 16 bit ASN 
> directly from ARIN.
> 
> 3) They have so much equipment scattered around the world with the old ASN, 
> that they do not want to renumber just because their headquarters moved to a 
> region served by a different RIR.  If the region moved to is ARIN, in most 
> cases they can save money by putting the moved ASN on their registration plan 
> with their address space.
> 
> In any case, if ARIN allows transfers, it is highly unlikely that that policy 
> would ever be applied to anything other than a 16 bit ASN as there are plenty 
> of 32 bit ASN's available in all regions.

All three scenarios apply equally to 16 and 32 bit ASNs. If it’s easier for 
everyone involved to transfer an ASN between RIRs along with any IPv4 
resources, there’s no reason to renumber (which requires cooperation from BGP 
peers). 

-Scott

>> On Fri, 2 Feb 2018, Aaron Dudek wrote:
>> 
>> Why would there be a need for a company to transfer an ASN between RIRs?
>> 
>> 
>>> On Thu, Feb 1, 2018 at 7:17 PM, David Farmer  wrote:
>>> I'm not sure what you are asking, but there are no technical or policy
>>> requirements, at least that I'm aware of, that an ASN only routes address
>>> blocks from the same registry.  In other words, a RIPE ASN can route ARIN IP
>>> blocks and vice versa.
>>> 
>>> But this does bring up an interesting question; we have the IRR consultation
>>> going on, what should happen to IRR objects when ASNs or IP blocks are
>>> transferred to another RIRs?
>>> 
>>> My point was this policy is about ASN transfers if we want to talk about
>>> IPv6 transfers that would be a different policy, and therefore should be a
>>> different thread.  It makes it easier to discern the support for a policy if
>>> side threads are split out.
>>> 
>>> Thanks
>>> 
 On Thu, Feb 1, 2018 at 12:21 PM, Roberts, Orin  wrote:
 
 You could, but then IPv6 routing/fragmentation becomes an issue.
 
 
 
 Unless when an ASN is transferred from ARIN all IP networks associated to
 that ASN are revoked/removed/deleted from ARIN.
 
 ie. I can acquire an ASN that currently exists at ARIN minus any
 associated IP networks, move it to APNIC/RIPE, then associate IP networks
 from APNIC/RIPE.
 
 
 
 ~the same for the reverse.
 
 
 
 A proviso would then be, only a clean(ed) ASN can be transferred in/out.
 
 
 
 Orin Roberts
 
 
 
 From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of David
 Farmer
 Sent: February-01-18 1:03 PM
 To: Job Snijders 
 Cc: arin-ppml@arin.net
 Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1:
 Allow Inter-regional ASN Transfers
 
 
 
 First, let's move IPv6 transfers out of the ASN transfers thread.
 
 
 
 On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders  wrote:
 
 On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmas...@uneedus.com wrote:
> I would be opposed to allowing inter regional IPv6 Transfers.
> 
> One of the main benefits of IPv6 over IPv4 is the reduction of routing
> table size.  Allowing inter regional transfers would start the road to
> larger routing tables.
 
 I'd appreciate evidence that allowing interregional transfers leads to
 larger routing tables. Administrative resource management is somewhat
 orthogonal to BGP announcements. Whether the resource is managed by RIR
 A vs RIR B bears no direct relation to the BGP announcements and routing
 tables.
 
 
 
 I agree, Inter-RIR transfers doesn't itself imply that the routing table
 will grow. However, the high level allocations from IANA to the RIRs which
 are fairly clean in IPv6 today will become fragmented, and likely seriously
 fragmented if their is signifigant inter-RIR transfers of IPv6. By itself
 this isn't necessarily a problem, however, IPv6 allocations and assignments
 have been made in a way to allow most of them to be enlarged in place.  If
 an allocation is transfered this is no longer easily possilbe to expand the
 alloation in place.
 
 
 
> We allowed a lot of this in IPv4 because of shortages of addresses.
> This is not in fact true in the IPv6 world. Growth in address use in
> IPv4 

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

[Scott Leibrand]

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 written seems appropriate 
> until we identify a reason to change it. 


Do you know of any organizations transferring blocks larger than a /24 for whom 
officer-attested justification is burdensome (to them or to ARIN)?

Scott

> On Jan 19, 2018, at 12:35 AM, David Farmer  wrote:
> 
> Owen, I think you are justified in taking an "I told you so!"
> 
> But, here are the two options as I see them to harmonize things;
> 
> 1. Change 4.2.2 to /24
> 
> 2. Change 8.5.3 to /21
> 
> I think Owen is saying #2, and the best I could glean from the previous 
> comments most we leaning toward #1.  
> 
> So, which way do people think we should go, #1 or #2?
> 
> Thanks.
> 
>> On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong  wrote:
>> Well, section 4 doesn’t govern transfers since we decoupled it anyway, so 
>> I’m not sure if we want to make staff behavior consistent or not. I would 
>> argue that moving the transfer boundary to /21 would make more sense than 
>> moving the section 4 boundary to /24, if we are going to synchronize them.
>> 
>> However, as you point out, transfers are governed by 8.5.5 and only free 
>> pool is governed by section 4 unless section 4 is referenced by section 8.
>> 
>> As you may recall, I opposed this decoupling because of the confusion and 
>> disparity in protocol I expected to result. Now we’re exactly where I 
>> predicted we’d be.
>> 
>> Owen
>> 
>>> On Jan 18, 2018, at 3:03 PM, David Farmer  wrote:
>>> 
>>> From the updated problem statement: If an organization applies under 
>>> section 8 first they are initially qualified for a /24, larger allocations 
>>> require additional documentation as noted in 8.5.5.
>>> 
>>> Again, whether a change in policy or staff practice, what do we want to 
>>> happen?
>>> 
 On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong  wrote:
 The existing language “up to a /21” is consistent with staff allowing you 
 to obtain a /24 via transfer.
 
 Are you telling me that staff is refusing /21 transfers, but allowing /24 
 transfers to new ISPs without further justification? If so, I would argue 
 that current staff practice is in error vs. policy language.
 
 Owen
 
> On Jan 18, 2018, at 2:37 PM, David Farmer  wrote:
> 
> Owen,
> 
> Yep, that was an editing error, it should have been; 
> 
> 4.2.2. Initial allocation to ISPs
> 
> All ISP organizations without direct assignments or allocations from ARIN 
> qualify for an initial allocation of a /24. Organizations may qualify for 
> a larger initial allocation by documenting how the requested allocation 
> will be utilized within 24 months.
> 
>> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong  wrote:
>> I see no reason to move the boundary for an ISP initial allocation from 
>> /21 to /24.
> 
> Well that seems to be staff intrupretation if you are getting an initial 
> allocation via a transfer, how would you reslove this then?
> 
> Thanks.
>  
>> I certainly see no reason for “up to a /24” as there’s nothing smaller 
>> available and even if it were, it wouldn’t be useful in any foreseeable 
>> environment.
>> 
>> Owen
>> 
>>> On Jan 18, 2018, at 2:21 PM, David Farmer  wrote:
>>> 
>>> David, 
>>> 
>>> The resolution you suggest below seems like a different policy proposal 
>>> to me, one with a significantly broader scope than this draft policy 
>>> has.  But I think it is a valid question for the community to consider, 
>>> it's just not really the problem statement in question for this Draft 
>>> Policy.
>>> 
>>> So, back within the scope of this Draft Policy as the shepherd, I plan 
>>> to push forward Andrew's updated Problem Statement with a Policy 
>>> Statement that harmonizes and simplifies the text in section 4.2.2 as 
>>> an official update to this Draft Policy to get the conversation moving 
>>> again.  
>>> 
>>> The current text of 4.2.2 is;
>>> 
>>> 4.2.2. Initial allocation to ISPs
>>> 
>>> All ISP organizations without direct assignments or allocations from 
>>> ARIN qualify for an initial allocation of up to a /21, subject to 
>>> ARIN's minimum allocation size. Organizations may qualify for a larger 
>>> initial allocation by documenting how the requested allocation will be 
>>> utilized within 24 months. ISPs renumbering out of their previous 
>>> address space will be given a reasonable amount of time to do so, and 
>>> any blocks they are 

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

[Scott Leibrand]

Section 8 as discussed on PPML and as written gives anyone the ability to 
transfer a /24 without justification and requires officer-attested 
justification for anything larger. 

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 written seems appropriate until we 
identify a reason to change it. 

Scott

> On Dec 5, 2017, at 8:40 AM, Andrew Dul <andrew@quark.net> wrote:
> 
> I would agree there is nothing special about /21, that is just where we ended 
> up at exhaustion.  
> 
> It is possible this draft policy doesn't do what the community wants us to 
> do.  I wrote this draft as a followup to the policy experience report to 
> continue the conversation about the issue and to correct the inconsistency.  
> (Normally, I think of inconsistencies as a "bad" thing in policy)  
> 
> Perhaps what we really do want is a more strict interpretation of the new 
> section 8 transfer policy?  If so we need a way to signal that to staff.  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, especially (as Scott 
>> Leibrand asked for) absent statistics from the staff (if any such stats make 
>> sense).  With section 8 policy now wholly separated from section 4 policy, I 
>> sort of think that it’s the staff who should change their practices, and 
>> follow section 8 policy as written.  
>> 
>> Further to your problem statement, ISPs should NOT be applying under 
>> section 4 anymore. We know, however, from staff reports at the recent ARIN 
>> meeting that they still are applying.  That’s a definite problem, but it 
>> feels to me to be a different problem than what you are tackling in this 
>> draft policy proposal. 
>> 
>> Happy to hear and be swayed by data or other arguments.
>> 
>> David 
>> 
>> Sent from my iPhone
>> 
>> On Dec 4, 2017, at 4:30 PM, Andrew Dul <andrew@quark.net> wrote:
>> 
>>> Scott,  how would you feel about this proposed updated problem statement 
>>> which focuses on the current issue rather than the past.
>>> 
>>> Andrew
>>> 
>>> Problem Statement: 
>>> 
>>> It was noted at the ARIN 40 Policy Experience Report, that there is an 
>>> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that 
>>> the initial ISP block size should be /21 whereas the initial block size in 
>>> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This 
>>> causes ISP organizations to be approved for different initial block size 
>>> depending on if they first apply apply for a transfer directly under 
>>> section 8 or if they apply for a block under section 4.  This policy is 
>>> intended to clarify this issue, by setting a consistent ISP initial IPv4 
>>> block size. It was noted that ARIN staff current operational practice is to 
>>> allow all ISPs an initial /21 for Section 8 transfers. 
>>> 
>>> 
>>>> On 11/21/2017 9:19 PM, Scott Leibrand wrote:
>>>> I’d be ok with a /21, but there’s nothing magical about that size in a 
>>>> post-exhaustion world. I’d rather base a loosening on actual transfer 
>>>> statistics, and consider doing so for both allocations and assignments. 
>>>> 
>>>> Scott
>>>> 
>>>> On Nov 21, 2017, at 7:28 PM, Andrew Dul <andrew@quark.net> wrote:
>>>> 
>>>>> It sounds like our recollections of what we intended for ISP initial 
>>>>> allocations have diverged. I will admit when I drafted the problem 
>>>>> statement I did not go back through email to see if there was anything 
>>>>> about this issue.
>>>>> 
>>>>> Assuming we harmonize the problem statement, would you prefer 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 <scottleibr...@gmail.com> 
>>>>> wrote:
>>>>> 
>>>>>> I believe this problem statement is incorrect, and therefore oppose the 
>>>>>

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

[Scott Leibrand]

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 IPv4 /24 currently assigned.
>
>
>
> I held onto a /16 at a previous company, just because it was cool but had
> no use for it.  I checked recently and it is still assigned to the same
> company and not being used 15 years later.
>
>
>
> By adding a $25k monthly fee, they would quickly return the block.
>
>
>
> Currently we have to pay brokers or sellers to acquire more IPv4 space. I
> would rather pay ARIN which could go to better funding the organization.
>
>
>
> *From:* ARIN-PPML [mailto:arin-ppml-boun...@arin.net] *On Behalf Of *Austin
> Murkland
> *Sent:* Monday, November 27, 2017 3:26 PM
> *To:* Andre Dalle 
> *Cc:* ARIN-PPML List 
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC
> Validation Upon Reassignment
>
>
>
> Also support this
>
>
>
> On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle  wrote:
>
>
> All my IPv4 space is reassigned, and I discovered last year that not all
> of it - from the same carrier - is properly associated with us.
>
> Upstream created a POC for us (even though we were an existing customer
> with multiple reassignments), and it's been sluggish getting them to
> sort it out.  We have rDNS, so most abuse reporting still finds us, but
> some abuse mechanisms out there rely on POC info.
>
> So I think this is necessary.  +100 from here as well.
>
> 
> André Dalle
> Systems Administrator
> National Capital FreeNet [http://www.ncf.ca]
>
>
> - Original Message -
> From: "Joe Provo" 
> To: "ARIN-PPML List" 
> Sent: Wednesday, 22 November, 2017 11:01:59
> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC
> Validation Upon Reassignment
>
> On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote:
> > Thank you Scott.  As the co-author, I very much recognize this
> > proposal text is a ???first draft???.  Working with my co-author
> > Jason Schiller, and having solicited feedback from the AC, this
> > proposal was submitted to solve the general problem.  My hope was
> > the mechanics would be looked at critically by the community during
> > the PDP, and we would work together to improve them.
>
> With my personal hat on I'm very happy to see this getting
> to discussion. +100 for intent and I look forward to useful
> language suggestions here.
>
> --
> Posted from my personal account - see X-Disclaimer header.
> Joe Provo / Gweep / Earthling
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

Thanks for that context.

In that case, I stand corrected, and am even more strongly in favor of this
proposal.  :-)

-Scott

On Tue, Nov 21, 2017 at 4:16 PM, David Farmer <far...@umn.edu> wrote:

> No it actively requires a significant workload by ARIN Staff, which is why
> I believe it was brought to the communities attention.
>
> From slide #5 of the ARIN 40 Policy Experience Report;
>
>  Ticket Workload {for 4.2.3.5.}, 1,327 in 2016, approximately 70% are self
> SWIPs
>
> Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN
> _40/PDF/PPM/sweeting-policy-experience.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 that helps.
>
> On Tue, Nov 21, 2017 at 5:05 PM, Scott Leibrand <scottleibr...@gmail.com>
> wrote:
>
>> +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 <i...@arin.net> wrote:
>>
>>> On 16 November 2017 the ARIN Advisory Council (AC) advanced
>>> "ARIN-prop-248: Remove ARIN Review Requirements for Large IPv4
>>> Reassignments/Reallocations" to Draft Policy status.
>>>
>>> Draft Policy ARIN-2017-13 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2017_13.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-13: Remove ARIN Review Requirements for Large
>>> IPv4 Reassignments/Reallocations
>>>
>>> Problem Statement:
>>>
>>> ARIN review of large IPv4 reassignments or rellocations was put in place
>>> when ARIN had a free pool of IPv4 addresses. The main purpose of the review
>>> was to ensure that ISPs were following RFC2050 and ARIN policy for large
>>> blocks. Since there is no longer a free pool and blocks have a value
>>> through transfer, there is now a disincentive for ISPs to over assign
>>> blocks to downstream customers. Thus this policy is no longer needed.
>>>
>>> Policy statement:
>>>
>>> Remove Section 4.2.3.5 of NRPM
>>>
>>> Comments:
>>>
>>> Timetable for implementation: Immediate
>>> ___
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@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@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>
>
>
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://maps.google.com/?q=2218+University+Ave+SE=gmail=g>
>   Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

+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 Requirements for Large IPv4
> Reassignments/Reallocations" to Draft Policy status.
>
> Draft Policy ARIN-2017-13 is below and can be found at:
> https://www.arin.net/policy/proposals/2017_13.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-13: Remove ARIN Review Requirements for Large
> IPv4 Reassignments/Reallocations
>
> Problem Statement:
>
> ARIN review of large IPv4 reassignments or rellocations was put in place
> when ARIN had a free pool of IPv4 addresses. The main purpose of the review
> was to ensure that ISPs were following RFC2050 and ARIN policy for large
> blocks. Since there is no longer a free pool and blocks have a value
> through transfer, there is now a disincentive for ISPs to over assign
> blocks to downstream customers. Thus this policy is no longer needed.
>
> Policy statement:
>
> Remove Section 4.2.3.5 of NRPM
>
> Comments:
>
> Timetable for implementation: Immediate
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

+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 ARIN Advisory Council (AC) advanced
> "ARIN-prop-247: Require New POC Validation Upon Reassignment" to Draft
> Policy status.
>
> Draft Policy ARIN-2017-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2017_12.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-12: Require New POC Validation Upon Reassignment
>
> Problem Statement:
>
> Some large ISPs assign individuals to be POCs for reassigned blocks
> without consultation of the individual they are inserting into Whois. One
> year later, the POC is contacted by ARIN as part of Annual POC Validation
> policies.  The POC often does not know who ARIN is, what Whois is, and why
> they are in Whois.
>
> This policy proposal seeks to improve the situation where a POC is
> unwittingly and unwantingly inserted into Whois.
>
> It also seeks to mitigate the significant amount of time that ARIN staff
> reports that they spend fielding phone calls from POCs who have no idea
> they are in Whois.
>
> Finally, it is hopeful that this proposal will improve the overall POC
> validation situation, by forcing ISPs and customers to work together to
> insert proper information into Whois at the time of sub-delegation.
>
> Policy statement:
>
> Insert two new sections into NRPM 3:
>
> 3.7 New POC Validation Upon Reassignment
>
> When an ISP submits a valid reallocation or detailed reassignment request
> to ARIN which would result in a new POC object being created, ARIN must
> (before otherwise approving the request) contact the new POC by email for
> validation. ARIN's notification will, at a minimum, notify the POC of:
>
> - the information about the organization submitting the record; and
> - the resource(s) to which the POC is being attached; and
> - the organization(s) to which the POC is being attached.
>
> If the POC validates the request, the request shall be accepted by ARIN
> and the new objects inserted into Whois.  If the POC does not validate the
> request within 10 days, ARIN must reject the request.
>
> 3.8 Downstream Validation of Simple Reassignments
>
> When an ISP submits a valid simple reassigment request to ARIN with an
> organization name OR postal address that is identical to one or more
> existing OrgIDs, ARIN will notify the downstream organization and obtain
> guidance on whether to accept the simple reassigment, or redirect it to one
> of the existing OrgIDs as a detailed reassignment.
>
> Comments:
>
> Timetable for implementation: Immediate
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

+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 be found at:
> https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address Space
> (NRPM Section 4.2.1.6)
>
> Problem Statement:
>
> Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM)
> provides that an ISP having an immediate need for IPv4 address space that
> will be utilized within thirty days of a request may obtain a block of IPv4
> address space of the size specified in section 4.2.1.6 from ARIN on an
> exceptional basis. However, as noted in the ARIN 40 Policy Experience
> Report, since IPv4 exhaustion, obtaining IPv4 addresses in this manner is
> no longer possible as a practical matter. Instead an ISP must join the
> waiting list and wait until it reaches the front of the queue to obtain any
> IPv4 address space, however long that may take. In effect, section 4.2.1.6
> is non-operative. Accordingly, its continued presence in the NRPM is
> misleading and confusing.
>
> Policy statement:
>
> Section 4.2.1.6 of the NRPM is hereby repealed and section number 4.2.1.6
> is hereby retired.
>
> Comments:
>
> a. Timetable for implementation: Immediate
>
> b. Comments: Given the constraints created by the exhaustion of IPv4
> addresses, this proposal does not require any changes in the current ARIN
> practices for the allocation of IPv4 address space.
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

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 4.2.2.

8.5.5 reads "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."

The intention was that any ISP needing a /21 would need to "provide
documentation to ARIN which details the use of at least 50% of the
requested IPv4 block size within 24 months", with officer attestation to
same.

If that policy is deemed insufficient, and we believe it's better to allow
transfers of up to /21 without providing documentation to ARIN and officer
attestation of such, then this proposal would need to be re-written with a
new problem statement justifying that.

-Scott

On Tue, Nov 21, 2017 at 2:40 PM, ARIN  wrote:

> On 16 November 2017, the ARIN Advisory Council (AC) advanced
> "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers"
> to Draft Policy status.
>
> Draft Policy ARIN-2017-9 is below and can be found at:
> https://www.arin.net/policy/proposals/2017_9.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-9: Clarification of Initial Block Size for IPv4 ISP
> Transfers
>
> Problem Statement:
>
> It was noted at the ARIN 40 Policy Experience Report, that there is an
> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that
> the initial ISP block size should be /21 whereas the initial block size in
> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The
> intent of the new 8.5.4 was to match the previous policy. This policy is
> intended to clarify this issue. It was noted that ARIN staff current
> operational practice is to allow ISPs an initial /21 for Section 8
> transfers.
>
> Policy statement:
>
> Add the following to 8.5.4
>
> ISP organizations without direct assignments or allocations from ARIN
> qualify for an initial allocation of up to a /21.
>
> Comments:
>
> a. Timetable for implementation: Immediate
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

+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 the policy to Last Call
(and on to the board, if no un-considered objections are raised) without
another public policy meeting/consultation.

-Scott

On Wed, Oct 11, 2017 at 12:16 PM, ARIN  wrote:

> The ARIN Advisory Council (AC) met on 6 October 2017 and decided to send
> the following to Last Call:
>
> Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration
> Requirements
>
> The AC provided the following statement to the community:
>
> "Based on strong community support - on both the Public Policy Mailing
> List and in person at ARIN 40 during the policy consultation - for
> replacing the "should" qualifier in section 6.5.5.4 with "shall", the
> Advisory Council, after careful review and discussion, has made the
> requested change to the text."
>
> Feedback is encouraged during the Last Call period. All comments should be
> provided to the Public Policy Mailing List. This Last Call period will
> expire on 10 November 2017. After Last Call, the AC will conduct their Last
> Call review.
>
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> AC's Statement of Conformance with ARIN's Principles of Internet Number
> Resource Policy:
>
> This proposal is technically sound and enables fair and impartial number
> policy for easier IPv6 Registrations. The staff and legal review noted a
> single clarification issue which has been addressed. There is ample support
> for the proposal on PPML and no concerns have been raised by the community
> regarding the proposal.
>
> Problem Statement:
>
> Current ARIN policy has different WHOIS directory registration
> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
> triggered for an assignment of any address block equal to or greater than a
> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs
> for an assignment of any block equal to or greater than a /64, which
> constitutes one entire IPv6 subnet and is the minimum block size for an
> allocation. Accordingly, there is a significant disparity between IPv4 and
> IPv6 WHOIS registration thresholds in the case of assignments, resulting in
> more work in the case of IPv6 than is the case for IPv4. There is no
> technical or policy rationale for the disparity, which could serve as a
> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
> eliminate the disparity and corresponding adverse consequences.
>
> Policy statement:
>
> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
> "assignment containing a /64 or more addresses" and change to
> "re-allocation, reassignment containing a /47 or more addresses, or
> subdelegation of any size that will be individually announced,”
>
> and
>
> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
> to strike the text "4.2.3.7.1" and change to “6.5.5.1"
>
> and
>
> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
> deleting the phrase "holding /64 and larger blocks"
>
> and
>
> 4) Add new section 6.5.5.4  "Registration Requested by Recipient" of the
> NRPM, to read: "If the downstream recipient of a static assignment of /64
> or more addresses requests publishing of that assignment in ARIN's
> registration database, the ISP shall register that assignment as described
> in section 6.5.5.1."
>
> Comments:
>
> a.Timetable for implementation: Policy should be adopted as soon as
> possible.
>
> b.Anything else:
>
> Author Comments:
>
> IPv6 should not be more burdensome than the equivalent IPv4 network size.
> 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 which do not trigger any ARIN
> registration requirement when using IPv4. This is NOT true when these same
> exact customers use IPv6, as 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 

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

[Scott Leibrand]

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
> impression
> that it is any more optional than 6.5.5.1.
>
> It sounds like enforcement of 6.5.5.4 "shall" could reasonably
> match 6.5.5.1 shall.
>
>
> Talking off line I get the impression that some people thought the intent
> was that
> a single complaint of a downstream customer could trigger consequences
> (i.e. potential revocation of the IPv6 number resources.)  That is not my
> intention.
>
> My intention is that a single violation of 6.5.5.4 makes the ISP just as
> much out of
> compliance with number resource policy as a single violation of 6.5.5.1.
>
>
> I support shall.
>
> Anyone else support shall for both.5.5.4 and 6.5.5.1?
> Oppose shall for 6.5.5.4 but support it for 6.5.5.1?
> Oppose shall for both 6.5.5.4 and 6.5.5.1?
> Either is fine?
> Don't really care?
>
> Support shall for both: 2
> Oppose shall for 6.5.5.4 but support it for 6.5.5.1: 0
> Oppose shall for both: 0
> Either: 0
> don't care: 0
>
> (I count 7 unique posters in this thread,
> and another 27 across other posts on this policy...
> Of course a bunch of that is concerned with residential privacy and DNS)
>
>
> ___Jason
>
> On Thu, Sep 28, 2017 at 1:16 AM, james machado 
> wrote:
>
>> I oppose as written.
>>
>>   I support Jason's language of replacing "should" with "shall" in
>> 6.5.5.4.
>>
>> James
>>
>>
>>
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>
>
>
> --
> ___
> Jason Schiller|NetOps|jschil...@google.com|571-266-0006 <(571)%20266-0006>
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

+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 of the Recommended Draft Policy is below, and may also be found
> at:
>
> https://www.arin.net/policy/proposals/2017_5.html
>
> You are encouraged to discuss all Recommended Draft Policies on PPML
> prior to their presentation at the next ARIN Public Policy and Members
> Meeting. PPML and PPC discussions are invaluable to the AC when
> determining community consensus.
>
> 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)
>
>
>
> AC's Statement of Conformance with ARIN's Principles of Internet Number
> Resource Policy:
>
> This proposal is technically sound and enables fair and impartial number
> policy for easier IPv6 Registrations. The staff and legal review noted a
> single clarification issue which has been addressed. There is ample support
> for the proposal on PPML and no concerns have been raised by the community
> regarding the proposal.
>
> Problem Statement:
>
> Current ARIN policy has different WHOIS directory registration
> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
> triggered for an assignment of any address block equal to or greater than a
> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs
> for an assignment of any block equal to or greater than a /64, which
> constitutes one entire IPv6 subnet and is the minimum block size for an
> allocation. Accordingly, there is a significant disparity between IPv4 and
> IPv6 WHOIS registration thresholds in the case of assignments, resulting in
> more work in the case of IPv6 than is the case for IPv4. There is no
> technical or policy rationale for the disparity, which could serve as a
> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
> eliminate the disparity and corresponding adverse consequences.
>
> Policy statement:
>
> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
> "assignment containing a /64 or more addresses" and change to
> "re-allocation, reassignment containing a /47 or more addresses, or
> subdelegation of any size that will be individually announced,"
>
> and
>
> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
> to strike the text "4.2.3.7.1" and change to "6.5.5.1"
>
> and
>
> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
> deleting the phrase "holding /64 and larger blocks"
>
> and
>
> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the
> NRPM, to read: "If the downstream recipient of a static assignment of /64
> or more addresses requests publishing of that assignment in ARIN's
> registration database, the ISP should register that assignment as described
> in section 6.5.5.1."
>
> Comments:
>
> a. Timetable for implementation:
>
> Policy should be adopted as soon as possible.
>
> b. Anything else:
>
> Author Comments:
>
> IPv6 should not be more burdensome than the equivalent IPv4 network size.
> 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 which do not trigger any ARIN
> registration requirement when using IPv4. This is NOT true when these same
> exact customers use IPv6, as 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. The administrative burden of
> 100% customer registration of IPv6 customers is unreasonable, when such is
> not required for those customers receiving only IPv4 connections.
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are