Re: [arin-ppml] Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation

[Chris Woodfield]

I’d argue that the examples you point out are a bit different, as in they are 
inherent aspects of the specific technologies and functionality that ARIN is 
charged with its stewardship of (in this case, IP and AS resources), but does 
not necessarily call out a specific technology other than those. 

As a counterexample, there are no references to BGP in the NRPM; while it’s 
highly unlikely that a new protocol will overtake it, there would be no needed 
changes to the NRPM to accommodate should that happen. More importantly, should 
there be a technical need and will to standardize on a new protocol to replace 
BGP, there’s zero concern that ARIN policy will slow the development or 
adoption of such a technology.

(True, the chances of BGP being eclipsed by a new protocol are probably lower 
than the chances of Ethernet being replaced, but I don’t think that dilutes the 
argument here.)

This is my main concern around the use “Ethernet” in this proposal - it’s not 
that we are simply acknowledging what is standard practice today, but I would 
never want ARIN policy to be a blocker for the adoption of new technologies, 
and the more specific we get about what technologies are required per policy, 
the higher that risk becomes.

Thanks,

-Chris


> On May 29, 2024, at 07:34, Martin Hannigan  wrote:
> 
> 
> 
> On Wed, May 29, 2024 at 01:22 Owen DeLong  > wrote:
>> Again, I think (and if I were involved in Open-IX would argue there) that 
>> their standard is over-specified and over-constrained. While 802.3z and 
>> 802.3ae are very common interfaces today, I know, for example, that there 
>> are at least a couple of IXPs that are considering (if not implemented) the 
>> elimination of 802.3z and moved up to 802.3ae as a minimum IX connection. I 
>> think the days of every IX offering 1Gpbs connections are certainly numbered 
>> as 10G becomes ever cheaper to implement.
> 
> I hear you. We disagree (rarely).  The benefit is we close a massive hole in 
> policy and not replace one loop hole with another. There are other 
> prescriptive requirements in the NRPM. Multihoming.  6.4.4. Minimum 
> allocation sizes. Policies by shepherd singling out IX allocation sizes eg 
> /26. IETF -> IANA global instructions. Nothing really new here. 
> 
> HTH
> 
> -M<
> 
> 
> 
> 
> 
> 
> ___
> 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-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation

[Chris Woodfield]

> On May 23, 2024, at 19:17, Tyler O'Meara via ARIN-PPML  
> wrote:
> 
> I like Owen's proposed language. I think it strikes the right balance between
> being restrictive enough to prevent purely virtual IXes (which are cool, but
> shouldn't qualify under 4.4) while not being overly prescriptive on how IX
> operators need to design and run their IXes.
> 
> As a point of discussion, if an IX used VXLAN for the peering LAN to connect
> multiple DCs in the same metro area (using some kind of non-Internet 
> connection
> (DF, wave, etc) as the underlay), would this be an IX we want to be eligible
> under 4.4? My opinion is yes, this is a "real" IX that should qualify 
> (assuming
> it meets the other requirements).
> 

Your point of discussion is not theoretical - I’m aware at least two major IXes 
utilizing VXLAN today, albeit running on their own physical switches (and yes, 
over physical ethernet ports). Would this fit the description of the “virtual 
IX” that the authors state should not qualify for CII resources under this 
proposal? I don’t think that’s intended, but we should make sure this is clear.


> Tyler
> 
> On Thu, 2024-05-23 at 21:54 -0400, Martin Hannigan wrote:
>> 
>> 
>> On Thu, May 23, 2024 at 21:31 Owen DeLong via ARIN-PPML 
>> wrote:
>>> I support the spirit of the draft policy, but I’d like to see a change that
>>> I don’t think will be controversial…
>>> 
>>> 1. ARIN should not be specifying network technologies. “A physically present
>>> ethernet switch” is way too specific for NRPM IMHO. I would propose,
>>> instead, that we specify “connected to a shared peering fabric via physical
>>> infrastructure (e.g. a shared ethernet switch).”
>>> 
>>> In the past, we have had internet exchanges that were (e.g.) ATM based and
>>> had multiple physical switches spread over a variety of locations. I don’t
>>> know that there are currently any non-ethernet based exchanges still in
>>> operation, but I also don’t know what kind of networking technology might
>>> occur next week. For example, I think it would be perfectly valid to set up
>>> an infiniband exchange if there were enough interested participants, but
>>> under this proposed policy, that would not be allowed.
>>> 
>>> Owen
>>> 
>> 
>> 
>> 
>>> 
>>> 
>> 
>> 
>> Thanks Owen. 
>> 
>> I’m one of four authors.  And many interested. Speaking for myself.
>> 
>> The reason its specific is to address specific issues. 
>> 
>> Virtual IX’s may be able to justify 4.4 resources and applying the hardware
>> test tries to prevent that. Many may claim Virtual IX are educational in
>> nature. This is good. However, they are not CI as a result and not in need of
>> precious 4.4 resources.
>> 
>> The other is IX preparing and certifying peers, getting resources but then
>> never deploying a switch fabric. Wanted to have a good revocation trigger.
>> Likely to be used rarely if ever, but for thoroughness. 
>> 
>> Neither are corner cases. 
>> 
>> On the switch tech l2 piece ATM etc does contradict demonstrated standards.
>> And if IX tech changes, policy could be changed. If someone tells ARIN 
>> they’re
>> deploying an ATM switch as an IX in 2024 it should set off alarm bells IMHO.
>> 
>> As long as the physical switch component is kept I don't think there would be
>> heartache. But hope the reasons help everyone understand the inside baseball.
>> 
>> 
>>> 
>>> 
 On May 21, 2024, at 09:26, ARIN  wrote:
 
 On 16 May 2024, the ARIN Advisory Council (AC) accepted “ARIN-prop-333:
 Rewrite of NRPM Section 4.4 Micro-Allocation” as a Draft Policy.
 
 Draft Policy ARIN-2024-5 is below and can be found at:
 
 https://www.arin.net/participate/policy/drafts/2024_5
 
 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-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation
 
 Problem Statement:  
 
 The current NRPM Section 4.4 language hasn’t aged well. As the ARIN 53
 policy experience report demonstrated, 4.4 has also become difficult to
 implement by ARIN staff. Growth and use of Internet Exchanges has also
 changed. The overhaul seeks to improve technical soundness, respect the
 privilege of a dedicated pool and to more closely observe conservation
 

Re: [arin-ppml] Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation

[Chris Woodfield]

In general, I support this proposal. 

Replying to selected points:

> On May 22, 2024, at 14:22, Tyler O'Meara via ARIN-PPML  
> wrote:
> 
> I support this change, but have a few suggestions:
> 
> 1) I'd use Critical Internet Infrastructure (CII) as the official term for 
> this
> section; Critical Infrastructure seems a bit too vague.

I like this change. +1

> 2) Instead of "ARIN will reserve", should we change it to "ARIN has reserved",
> since the reservation has already occurred and there's no intention in the
> policy to keep the reserved block at a /15 equivalent?

note that section 4.1.7.1 includes a mechanism by which the reserved block will 
be replenished  (presumably via reclaimed resources), so we can’t assume that 
it will only be a /15 going forward. See 
https://www.arin.net/participate/policy/nrpm/#4-1-7-2-precedence-for-replenishment

> 3) Add the following sentence to the 2nd paragraph: "IP Addresses allocated
> under this section must only be used for the operation of CII".
>The current wording permits an operator of CII to use 4.4 space for any
> purpose, which is likely not the intent.

I’m not going to speak for the authors, but I’d be in support of this language 
change. Usage of CII space outside the operation of CII does not likely fit 
with the communities expectations for this space (The community is welcome to 
disagree with me on this, of course).

> 4) In "Assigned addresses may be publicly reachable at the operators 
> discretion
> and be used to operate all of the Internet Exchange's infrastructure" replace
> "operators" with "operator's".

Likely a typo, in support of fixing of course.

Thanks,

-Chris


> 
> 
> On Tue, 2024-05-21 at 12:26 -0400, ARIN wrote:
>> On 16 May 2024, the ARIN Advisory Council (AC) accepted “ARIN-prop-333:
>> Rewrite of NRPM Section 4.4 Micro-Allocation” as a Draft Policy.
>> 
>> Draft Policy ARIN-2024-5 is below and can be found at:
>> 
>> https://www.arin.net/participate/policy/drafts/2024_5
>> 
>> 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-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation
>> 
>> Problem Statement:  
>> 
>> The current NRPM Section 4.4 language hasn’t aged well. As the ARIN 53 policy
>> experience report demonstrated, 4.4 has also become difficult to implement by
>> ARIN staff. Growth and use of Internet Exchanges has also changed. The
>> overhaul seeks to improve technical soundness, respect the privilege of a
>> dedicated pool and to more closely observe conservation principles using
>> clear, minimum and enforceable requirements and underscoring the value of
>> routability of assigned prefixes as required.
>> 
>> ARIN 4.4 CI Assignments
>> 
>> The intent of this policy is not to unreasonably preclude the use of an
>> allocated or assigned prefix in servicing the needs of critical 
>> infrastructure
>> of the Internet.
>> 
>> ARIN will reserve a /15 equivalent of IPv4 address space for Critical
>> Infrastructure (CI) of the Internet within the ARIN RIR service area.
>> Assignments from this pool will be no smaller than a /24. Sparse allocation
>> will be used whenever practical. CI includes Internet Exchanges, IANA
>> authorized root servers, ccTLD operators, ARIN, and IANA. Addresses assigned
>> from this pool may be revoked if no longer in use or not used for approved
>> purposes. Only Section 8.2 transfers are allowed. Use of this policy for CI 
>> is
>> voluntary. ARIN will publish all 4.4 allocated addresses for research
>> purposes.
>> 
>> 4.4.1 Internet Exchange Assignments
>> 
>> • Internet Exchange operators must justify their need by providing the
>> following:
>> 
>> • A minimum of three initial participants connected to a physically present
>> ethernet switch fabric to be used for the purpose of Internet Exchange
>> facilitated peering
>> 
>> • Justification must include:
>>  - Three unique participant names and ASNs not under common control
>>  - Direct contact information for each participant
>> 
>> • Staff can reasonably validate hardware existence and participants intent
>> 
>> • Applicant Internet Exchange affiliated ASNs are not eligible to be included
>> in meeting the participant requirement
>> 
>> • Assigned addresses may be publicly reachable at the operators discretion 
>> and
>> be 

Re: [arin-ppml] Revised - Draft Policy ARIN-2023-7: Clarification of NRPM Sections 4.5 and 6.11 Multiple Discrete Networks

[Chris Woodfield]

Speaking as the AC Shepherd for this proposal: This revision removes the 
definition of Organization ID (Org ID) that was originally present in the 
proposal, in response to community feedback taken during the last PPM meeting 
in October. The feedback at the mic favored separating the additional 
definition into a separate proposal, which is being done.

Thanks,

-Chris

> On Dec 19, 2023, at 11:22, ARIN  wrote:
> 
> The following Draft Policy has been revised:
> 
> * 2023-7: Clarification of NRPM Sections 4.5 and 6.11 Multiple Discrete 
> Networks
> 
> 
> Revised text is below and can be found at:
> 
> https://www.arin.net/participate/policy/drafts/2023_7/
> 
> 
> 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)
> 
> - 
> 
> Problem Statement:
> 
> Section 4.5 and 6.11 of the NRPM does not adhere to the style guide used by 
> the remainder of the document. The numbered lists in these two sections also 
> detracts from the readability and usability of the NRPM.
> 
> Policy Statement:
> 
> Current:
> 
> 4.5 Multiple Discrete Networks
> 
> Organizations with multiple discrete networks desiring to request new or 
> additional address space under a single Organization ID must meet the 
> following criteria:
> 
> The organization shall be a single entity and not a consortium of smaller 
> independent entities.
> 
> The organization must have compelling criteria for creating discrete 
> networks. Examples of a discrete network might include:
> 
> Regulatory restrictions for data transmission,
> 
> Geographic distance and diversity between networks,
> 
> Autonomous multihomed discrete networks.
> 
> The organization must keep detailed records on how it has allocated space to 
> each location, including the date of each allocation.
> 
> 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.
> 
> 
> The organization may not allocate additional address space to a location 
> until each of that location’s address blocks are 80% utilized.
> 
> The organization should notify ARIN at the time of the request their desire 
> to apply this policy to their account.
> 
> Upon verification that the organization has shown evidence of deployment of 
> the new discrete network site, the new network(s) shall be allocated the 
> minimum allocation size under section 4.2.1.5.
> Proposed:
> 
> 4.5 Multiple Discrete Networks
> 
> Organizations with multiple discrete networks desiring to request a new or 
> additional IP address space allocation under a single Organization ID must 
> meet the following criteria:
> 
> The organization shall be a single entity and not a consortium of smaller 
> independent entities and must have compelling criteria for creating discrete 
> networks.
> 
> Examples which may result in discrete networks might include:
> 
> - Regulatory restrictions for data- transmission;
> - Geographic distance and diversity between networks; or
> - Autonomous multihomed discrete networks.
> 
> The organization must keep detailed records on how it has allocated IP 
> addresses to each location, including the date of each allocation. When 
> applying for additional Internet Resource allocations from ARIN, the 
> organization must demonstrate utilization greater than 50% of both the last 
> IP addresses allocated and the aggregate sum of all IP addresses 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 IP address allocations by having all unallocated IP 
> address blocks smaller than ARIN’s current minimum allocation size. The 
> organization may not allocate additional IP address space to a location until 
> each of that location’s IP address allocations are 80% utilized. The 
> organization should notify ARIN at the time of the request of 

Re: [arin-ppml] AC candidates

[Chris Woodfield]

The concern, as I see it, is not whether or not a candidate has potential 
conflicts of interest - you are correct that it would be extremely difficult to 
find candidates that do not. The question for me is, can a given candidate be 
trusted to properly separate their personal business interests from the 
interests of the community, and recuse themselves a given deliberation when 
there’s no other way to remove the appearance of such a conflict of interest?

-C

> On Oct 26, 2023, at 08:12, Mike Burns  wrote:
> 
> Hi Bill,
> 
> Fair enough, most people interested in this are likely to have some conflicts 
> and it's important to consider those.
> 
> If we unilaterally excluded all candidates with conflicts though, candidate 
> pickings would be even slimmer.
> 
> Regards,
> Mike
> 
> 
> 
>  On Thu,26 Oct 2023 17:22:13 -0400 b...@herrin.us wrote 
> 
> On Thu, Oct 26, 2023 at 6:58 AM Mike Burns  > wrote: 
> > And I agree with Fernando that affiliations or connections to 
> > IP brokers would be a point in their favor considering they 
> > are the people distributing IPv4 addresses these days. 
> 
> Hi Mike, 
> 
> Before considering someone affiliated with an address broker for an 
> ARIN position, I'd want them to demonstrate that they recognize the 
> conflict of interest that's likely to pose and have a well conceived 
> plan for addressing it. 
> 
> Conflict of interest corrupts even the best intentioned. I once quit a 
> job I liked because despite his good intentions my boss unsuccessfully 
> managed his conflict of interest. It placed me in a position where I 
> couldn't properly oversee the prime vendor. So I'm sensitive to 
> conflicts of interest. 
> 
> 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-2: /26 initial IPv4 allocation for IXPs

[Chris Woodfield]

Andrew - You are correct that the micro-allocation pool can be replenished as 
needed from returned allocations. That said, it should be noted that IPv4 
allocations used for this purpose would be resources that, under current 
policy, would have presumably been allocated to organizations via the wait list 
otherwise.

Thanks,

- Chris


> On Jun 20, 2023, at 10:42, Andrew Dul  wrote:
> 
> I'd also like to point out that we already have a method for refilling the 
> IXP pool as needed.  The current policy states that ARIN should maintain at 
> least a 3 year supply for these reserved pools and so far it would also seem 
> that the returns to ARIN appear to be sufficient to add to the reserved pools 
> as necessary.
> 
> https://www.arin.net/participate/policy/nrpm/#4-1-7-2-precedence-for-replenishment
>  
> <https://www.arin.net/participate/policy/nrpm/#4-1-7-2-precedence-for-replenishment>
>  
> <https://www.arin.net/participate/policy/nrpm/#4-1-7-2-precedence-for-replenishment>
> 
> Andrew
> 
> On 6/20/2023 10:10 AM, Chris Woodfield wrote:
>> Speaking as the proposal author: It appears that a URL included in the draft 
>> language has been inadvertently eaten by formatting. The Statistics & 
>> Reporting link is here: 
>> https://www.arin.net/reference/research/statistics/#ipv4-reserved-pool-status-nrpm-4-10-ipv6-deployments
>> 
>> I’ll also note that this page appears to have been updated since the policy 
>> was originally submitted - it now appears that the NPRM 4.4 Micro-Allocation 
>> pool is 65% allocated, with 35% remaining. (There’s a good chance I was 
>> rounding down when I said 50% in the problem statement)
>> 
>> Thanks,
>> 
>> -Chris
>> 
>>> On Jun 20, 2023, at 08:54, ARIN  <mailto:i...@arin.net> 
>>> wrote:
>>> 
>>> On 15 June 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-320: 
>>> /26 initial IPv4 allocation for IXPs” as a Draft Policy.
>>>  
>>> Draft Policy ARIN-2023-2 is below and can be found at:
>>>  
>>> https://www.arin.net/participate/policy/drafts/2023_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,
>>>  
>>> Eddie Diego
>>> Policy Analyst
>>> American Registry for Internet Numbers (ARIN)
>>> 
>>> 
>>> Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs
>>> 
>>> Problem Statement: 
>>> 
>>> Per NRPM Section 4.4, ARIN has reserved a /15 for micro-allocations for 
>>> critical internet infrastructure, such as internet exchange points (IXPs) 
>>> and core DNS service providers. The majority of these allocation requests 
>>> are made by IXPs. As of the last ARIN report, roughly half of this 
>>> reservation is allocated (see Statistics & Reporting  Projections from ARIN 
>>> staff suggest that at current allocation rates, the remaining reserved 
>>> space may be exhausted in the next few years.
>>> 
>>> In parallel, an analysis of PeeringDB data conducted by the RIPE Address 
>>> Policy Working Group shows that approximately 70% of global IXPs have fewer 
>>> than 32 members registered with that site. An IXP this size could readily 
>>> operate with a /26 allocation, which would provide 100% overprovisioning 
>>> beyond their existing peer count. (Source: 
>>> https://github.com/mwichtlh/address-policy-wg )
>>> 
>>> Unlike other types of allocations, IXP peering networks are not required by 
>>> member networks to be globally reachable; only members of the IXP must be 
>>> able to reach the prefix. As such, there is no technical requirement that 
>>> an IXP allocation must be no smaller than a /24.
>>> 
>>> Policy statement:
>>> 
>>> Existing text:
>>> 
>>> 4.4. Micro-allocation
>>> 
>>> ARIN will make IPv4 micro-all

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

[Chris Woodfield]

Speaking as the proposal author: It appears that a URL included in the draft 
language has been inadvertently eaten by formatting. The Statistics & Reporting 
link is here: 
https://www.arin.net/reference/research/statistics/#ipv4-reserved-pool-status-nrpm-4-10-ipv6-deployments

I’ll also note that this page appears to have been updated since the policy was 
originally submitted - it now appears that the NPRM 4.4 Micro-Allocation pool 
is 65% allocated, with 35% remaining. (There’s a good chance I was rounding 
down when I said 50% in the problem statement)

Thanks,

-Chris

> On Jun 20, 2023, at 08:54, ARIN  wrote:
> 
> On 15 June 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-320: /26 
> initial IPv4 allocation for IXPs” as a Draft Policy.
>  
> Draft Policy ARIN-2023-2 is below and can be found at:
>  
> https://www.arin.net/participate/policy/drafts/2023_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,
>  
> Eddie Diego
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs
> 
> Problem Statement: 
> 
> Per NRPM Section 4.4, ARIN has reserved a /15 for micro-allocations for 
> critical internet infrastructure, such as internet exchange points (IXPs) and 
> core DNS service providers. The majority of these allocation requests are 
> made by IXPs. As of the last ARIN report, roughly half of this reservation is 
> allocated (see Statistics & Reporting  Projections from ARIN staff suggest 
> that at current allocation rates, the remaining reserved space may be 
> exhausted in the next few years.
> 
> In parallel, an analysis of PeeringDB data conducted by the RIPE Address 
> Policy Working Group shows that approximately 70% of global IXPs have fewer 
> than 32 members registered with that site. An IXP this size could readily 
> operate with a /26 allocation, which would provide 100% overprovisioning 
> beyond their existing peer count. (Source: 
> https://github.com/mwichtlh/address-policy-wg )
> 
> Unlike other types of allocations, IXP peering networks are not required by 
> member networks to be globally reachable; only members of the IXP must be 
> able to reach the prefix. As such, there is no technical requirement that an 
> IXP allocation must be no smaller than a /24.
> 
> Policy statement:
> 
> Existing text:
> 
> 4.4. Micro-allocation
> 
> ARIN will make IPv4 micro-allocations to critical infrastructure providers of 
> the Internet, including public exchange points, 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 /24. Multiple allocations 
> may be granted in certain situations.
> 
> Replace with:
> 
> 4.4 Micro-allocation
> 
> 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.
> 
> 4.4.1 Micro-allocations for Internet Exchange Points (IXPs)
> 
> An IXP requesting an initial IPv4 allocation from this reserved space will be 
> assigned a /26 by default. 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.
> 
> An IXP requesting an allocation under this section must have also requested, 
> or already received, an IPv6 allocation for the same purpose under Section 
> 6.10.1.
> 
> An allocation made to an IXP under this section may only be used for the 
> operation of its public peering LAN. No other uses are allowed.
> 
> An IXP that has received an IPv4 allocation under this section may request a 
> larger allocation once they have utilized more than 50% of their existing 
> one. Upon receiving the larger allocation, the IXP must migrate to the new 
> allocation and return their previous one to ARIN within 6 months.
> 
> Comments:
> 
> This proposal mirrors RIPE policy proposal 2023-01 (see 
> https://www.ripe.net/participate/policies/proposals/2023-01) which is 
> currently under 

Re: [arin-ppml] Draft Policy ARIN-2022-13: Clean-up of NRPM Section 2.10

[Chris Woodfield]

Speaking with my AC hat on and as a co-shepherd for this policy. For the 
record, I am not the author, but I, like many others deploying IPv6 in their 
own datacenters, would stand to benefit from this particular policy change.

Paul - I believe your assessment is correct. This language is intended to 
capture the use case where a /64 may be allocated to a virtual network (for 
example, routing a /64 to a hypervisor or k8s pod or node) as well as a 
physical network, which is what the current policy accounts for. As is, 
accounting for multiple VMs with independent IPs must be done on a per-VM 
basis, and AFAIK can’t be counted as individual /64s for usage-based 
justification. 

If the community finds this language unacceptably unclear, suggestions on 
different approaches to capturing this use case in language would be welcome :) 

-C

> On Aug 23, 2022, at 11:12 AM, Paul R. Tagliamonte  wrote:
> 
> It seems like this change would mean a single physical data is not "one site" 
> as defined by the end user rules if each 'customer' gets a globally routable 
> subnet.
> 
> That does seem like a good distinction, since a single site hosting 10,000 
> customers' virtual infrastructure should probably be treated differently than 
> a single site with a single subnet.
> 
>   Paul
> 
> 
> On Tue, Aug 23, 2022 at 2:05 PM David Farmer via ARIN-PPML 
> mailto:arin-ppml@arin.net>> wrote:
> Opposed as written.
> 
> I agree; the new definition is less clear and way more abstract, in my 
> opinion.  Further, without a more specific statement of a problem with or a 
> misunderstanding created by the current text, I would prefer to keep the 
> current text.
> 
> Thanks.
> 
> On Tue, Aug 23, 2022 at 12:13 PM Andrew Dul  > wrote:
> Opposed as written.  
> 
> I do not find the new definition to be clearer, I do not know what a 
> "non-divisible physical or virtual point" is or isn't
> 
> Andrew
> 
> On 8/23/2022 9:30 AM, ARIN wrote:
>> On 18 August 2022, the ARIN Advisory Council (AC) accepted "ARIN-prop-318: 
>> Clean-up of NRPM Section 2.10" as a Draft Policy.
>> 
>>  
>> 
>> Draft Policy ARIN-2022-13 is below and can be found at:
>> 
>>  
>> 
>> https://www.arin.net/participate/policy/drafts/2022_13/ 
>> 
>>  
>> 
>> 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-13: Clean-up of NRPM Section 2.10
>> 
>>  
>> 
>> Problem Statement:
>> 
>>  
>> 
>> This proposal continues the work that the ARIN AC NRPM Clean-up Working 
>> Group undertook to conduct an editorial review of the NRPM. It relates 
>> specifically to Section 2.10. The focus of this proposal is to both clarify 
>> and simplify the wording of the section.
>> 
>>  
>> 
>> Policy statement:
>> 
>>  
>> 
>> Replace the existing text: “The term End Site shall mean a single structure 
>> or service delivery address, or, in the case of a multi-tenant structure, a 
>> single tenant within said structure (a single customer location).” With the 
>> new text: “An End Point is the smallest non-divisible physical or virtual 
>> point in a network requiring IPv6 address space.”
>> 
>>  
>> 
>> Timetable for Implementation: Immediate
>> 
>>  
>> 
>> Anything Else: This proposal is intended to replace ARIN-prop-305 in part, 
>> but is not considered strictly editorial in nature.
>> 
>>  
>> 
>>  
>> 
>> 
>> 
>> ___
>> 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 
> ).

Re: [arin-ppml] Potentially black listed space

[Chris Woodfield]

I feel that pledging a “warranty” of sorts for allocated space is well beyond 
ARIN’s capabilities - ARIN doesn’t control routing, or blacklists, and has 
never shown any interest in having that control. At best, ARIN staff can make a 
best-effort attempt to alert upstream providers and blacklist operators that a 
specific block has been reclaimed and will be allocated to a new owner, but 
whether or not to act on that information is entirely out of ARIN’s hands. 

I’d be curious how many blacklist operators make use of the arin-issued data to 
remove reclaimed space from their lists? And has ARIN engaged in any outreach 
to blacklist operators on this data source?

-C

> On Aug 11, 2022, at 12:29 PM, Martin Hannigan  wrote:
> 
> 
> 
> On Thu, Aug 11, 2022 at 2:22 PM WOOD Alison * DAS 
>  wrote:
> Good afternoon PPML:
> 
>  
> It has been brought to the attention of the Policy Experience Working Group 
> that in rare circumstances it is possible that Internet resources re-issued 
> from revoked RSA space may have been on a block list or currently routed.  
> The ARIN staff  is very careful to make sure that any reissued space is not 
> routed so as to cause some unaware 3rd party problems with their business as 
> well as the new holder.  ARIN also aims to avoid providing space that appears 
> on block lists and is diligent in researching these issues.
> 
> 
> OK
> 
>  
>  
> As a community, would you like to see clarification in section 4.1.8, stating 
> something like:  Space revoked per the RSA has had no substantial routing 
> table usage since revocation and has met a six month hold time?
> 
> 
> 
> If the only option to fulfill my waitlist request was getting revoked 
> space(dirty) I would take it. Is leaving well enough alone (discretionary) 
> causing some other issue?
> 
> Hope that helps. Hopefully I understood this. 
> 
> -M<
> 
> 
> 
> ___
> 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] Deceased Companies?

[Chris Woodfield]

To be specific, are you referring to heirs of biological persons, or 
organizations? I only mentioned bio persons as an analogy, but you’re correct 
that there are registrants, legacy or otherwise, that are people, not 
organizations. To the extent that this is the policy for resources assigned to 
a deceased person, I’d be interested in seeing that documented.

-C

> On Jul 25, 2022, at 8:45 AM, Paul E McNary  wrote:
> 
> I was told by John in person that heirs/successors had no legal rights to 
> legacy resources. 
> This was also repeated by ARIN staff at the time.
> They would be automatically recovered on death.
> 
> - Original Message -
> From: "Chris Woodfield" 
> To: "Ronald F. Guilmette" , "arin-ppml" 
> 
> Sent: Monday, July 25, 2022 10:41:48 AM
> Subject: Re: [arin-ppml] Deceased Companies?
> 
> I’d expect that in the case of an assignee subject to the RSA/LRSA, this 
> would be a self-correcting issue - if the assignee or its successor does not 
> pay their registration fee, the resources would eventually reclaimed by ARIN 
> and eventually allocated via the waiting list. Other resources, however, 
> could easily stagnate and require remediation work to either connect to the 
> legal heir of the defunct assignee organization; just like biological 
> persons, there should be some effort to locate potential heirs/successor 
> organizations before officially declaring the resource abandoned. To my 
> knowledge, no such process exists.
> 
> -C
> 
>> On Jul 25, 2022, at 8:34 AM, Ronald F. Guilmette  
>> wrote:
>> 
>> Please allow me to ask a different but related question.
>> 
>> As I understand it, all ARIN members are obligated, on an annual basis,
>> to pay a fee to ARIN for their membership, and also some additional fees,
>> again annually, based upon their assigned number resources, and more
>> specifically, based upon the number thereof.
>> 
>> If any of that is not correct, then I hope and trust that someone will
>> gently correct me.
>> 
>> Assuming that it is correct however, is there anything within either the
>> RSAs or within the NRPM that obliges member entities to make these annual
>> payments to ARIN themselves, directly?  Or may some third party make some
>> such payments on behalf of, say, some specific member entity?
>> 
>> 
>> 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.

___
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] Deceased Companies?

[Chris Woodfield]

I’d expect that in the case of an assignee subject to the RSA/LRSA, this would 
be a self-correcting issue - if the assignee or its successor does not pay 
their registration fee, the resources would eventually reclaimed by ARIN and 
eventually allocated via the waiting list. Other resources, however, could 
easily stagnate and require remediation work to either connect to the legal 
heir of the defunct assignee organization; just like biological persons, there 
should be some effort to locate potential heirs/successor organizations before 
officially declaring the resource abandoned. To my knowledge, no such process 
exists.

-C

> On Jul 25, 2022, at 8:34 AM, Ronald F. Guilmette  
> wrote:
> 
> Please allow me to ask a different but related question.
> 
> As I understand it, all ARIN members are obligated, on an annual basis,
> to pay a fee to ARIN for their membership, and also some additional fees,
> again annually, based upon their assigned number resources, and more
> specifically, based upon the number thereof.
> 
> If any of that is not correct, then I hope and trust that someone will
> gently correct me.
> 
> Assuming that it is correct however, is there anything within either the
> RSAs or within the NRPM that obliges member entities to make these annual
> payments to ARIN themselves, directly?  Or may some third party make some
> such payments on behalf of, say, some specific member entity?
> 
> 
> 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] Revised - Draft Policy ARIN-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[Chris Woodfield]

Speaking in support, in a personal capacity.

More generally speaking, this is one place where I’d argue for more permissive 
policy, mainly towards the goal of consistent set of policies for all 
resources. While I can’t see a technical need at this point for an IPv6 or 
32-bit ASN transfer policy, I can see the potential for wanting to get out in 
front of a policy should it ever arise. I could also see the potential for 
non-technical needs for those types of transfers, such as vanity prefixes/ASNs 
(a debatable practice in its own right, but I’m sure there would be demand), or 
other potential drivers that none of us have considered to date.

Thanks,

-C

> On Jan 21, 2022, at 9:58 AM, 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.

Re: [arin-ppml] Update on Litigation Between AFRINIC and Cloud Innovation ltd

[Chris Woodfield]

It pains me to feel like I have to state the obvious, but a PR release from one 
of the parties in this dispute can hardly be considered a notable development 
worth posting to every RIR’s mailing list.

-C

> On Dec 26, 2021, at 3:45 AM, Cheken Chetty  wrote:
> 
> Hi all, 
> 
> I believe the Internet community is still concerned with the ongoings of the 
> lawsuit between Cloud Innovation and AFRINIC. Here's a post I saw recently : 
> 
> https://cloudinnovation.org/press-release3.html 
> .
> 
> Regards
> ___
> 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

[Chris Woodfield]

First, I invite ARIN staff or Trustees to please advise if discussion of active 
ASCP Suggestions is appropriate on PPML, and if not, please suggest an 
alternative forum for doing so. Would arin-consult@ be a more appropriate place 
for this discussion?

Reading both of these suggestions, I agree with the goals of both of these. 
That said, I would suspect that the language in 2021.22 calling for the 
publication of the NomCom’s explanation for rejecting a petitioning nominee may 
prove problematic from a privacy point of view. At the very least, it should be 
required that a declined nominee must be made explicitly aware of, and consent 
to, this disclosure as a part of the process of opening a petition.

-C

> On Oct 28, 2021, at 12:08 PM, Joe Provo  wrote:
> 
> On Mon, Oct 11, 2021 at 08:08:04PM -0700, Scott Leibrand wrote:
> [snip]
>> 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.
> [snip]
> 
> Folks interested in this topic and don't monitor the ACSP page
> for changes might want to note two recent Suggestions in this 
> vein:
> - https://www.arin.net/participate/community/acsp/suggestions/2021/2021-23/
> - https://www.arin.net/participate/community/acsp/suggestions/2021/2021-22/
> 
> Cheers!
> 
> Joe
> 
> 
> -- 
> 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 ARIN-2021-7: Make Abuse Contact Useful

[Chris Woodfield]

Change the proposed language in 2.1.2 from “must” to “may”, and develop (via 
IETF, or simply across RIRs) a standard API format for submitting reports, and 
I could support this policy.

Given such a standard does not exist, I am not inclined to support this 
proposal. If such a standard existed, I would support this as a new optional 
field, as Scott proposes, but not a mandatory field and not replacing the 
existing abuse contact field.

-C

> On Oct 27, 2021, at 11:39 AM, William Herrin  wrote:
> 
> On Wed, Oct 27, 2021 at 10:59 AM Scott Leibrand  
> wrote:
>> Backwards compatibility is important here. If we want to add URL 
>> capabilities, there's no reason it can't be a new field.
> 
> Hi Scott,
> 
> I buy the backwards compatibility theory. ARIN staff will have to
> comment but I think that's an implementation detail: the policy does
> not require them to remove the old abuse contacts; it just makes them
> optional and requires ARNI to add abuse URLs.
> 
> With that understanding, and/or a rewrite to make it clear, would you
> support the proposal?
> 
> 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-2021-4: Clarifications to Sections 8.3, 8.4 and 8.5.6

[Chris Woodfield]

I think Joe’s got a good suggestion that I would support - define “transferable 
number resources” as IPv4 addresses and ASNs in Section 2, and go from there.

-C

> On Oct 21, 2021, at 5:39 PM, Martin Hannigan  wrote:
> 
> 
> 
> On Thu, Oct 21, 2021 at 14:53 Chris Woodfield  <mailto:ch...@semihuman.com>> wrote:
> I support this edit, for same reasons others have mentioned. 
> 
> If I’m recalling yesterday’s presentation correctly, it was ARIN Staff and 
> Legal, not the AC, that determined that this language could not be 
> implemented an editorial change, so that’s not up for debate here.
> 
> One possible adjustment that I’d like to suggest is that the term “IPv4 
> and/or ASN resources” seems a bit awkward, given how many times it appears in 
> the section. Perhaps we could add a new section that incorporates David’s 
> suggested language, but also handles the clarification of the definition of 
> number resources in a single place, scoped to Section 8.
> 
> So, a new Section 8.1.1, which I’d propose would be named “Definitions”, 
> could read as follows:
> 
> 
>   All references to “number resources" in this section, unless stated 
> otherwise, refer to IPv4 addresses and/or ASN resources. 
> 
>   When number resources of multiple types, including IPv6 resources, are 
> transferred, each resource type is considered separately and independently, 
> both for any conditions on their transferability and the application of any 
> restrictions following a transfer.
> 
> 
> Following this, the other edits to Section 8 in the proposal can simply be 
> changed to “number resources” to suit.
> 
> Opinions?
> 
> -C
> 
> We’d be better off using defined terms. Easier to construct, but end up being 
> document global. 
> 
> Warm regards,
> 
> -M<
> 
> 
> 
> 
> 
>> On Oct 21, 2021, at 11:23 AM, Martin Hannigan > <mailto:hanni...@gmail.com>> wrote:
>> 
>> 
>> I agree with Owen re: the editorial nature of the changes. However, I 
>> support it moving forward. I don't support the Farmer suggestion. That is 
>> possibly a material change that should undergo the rigors of "the process" 
>> on its own.
>> 
>> Warm regards,
>> 
>> -M<
>> 
>> 
>> 
>> 
>> 
>> On Thu, Oct 21, 2021 at 11:33 AM Owen DeLong via ARIN-PPML 
>> mailto:arin-ppml@arin.net>> wrote:
>> I support this amendment.
>> 
>> Owen
>> 
>> 
>>> On Oct 20, 2021, at 12:45 , David Farmer via ARIN-PPML >> <mailto:arin-ppml@arin.net>> wrote:
>>> 
>>> I support this proposal as currently written. 
>>> 
>>> However, regarding Kevin Blumberg's comment at the ARIN 48 discussion of 
>>> this policy earlier today; How about adding a paragraph like the following 
>>> to section 8.1, Principles;
>>> 
>>> When number resources of multiple types, IPv4, IPv6, and/or ASNs, are 
>>> transferred, each resource type is considered separately and independently, 
>>> both for any conditions on their transferability and the application of any 
>>> restrictions following a transfer.
>>> 
>>> Something like this added to Section 8.1, Principles, along with the 
>>> already proposed changes should eliminate any possibility of confusion in 
>>> this regard.
>>> 
>>> Thanks
>>> 
>>> On Tue, Aug 24, 2021 at 7:52 AM ARIN mailto:i...@arin.net>> 
>>> 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/ 
>>> <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:
>>> 
>>>  
>>> 

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

[Chris Woodfield]

I support this edit, for same reasons others have mentioned. 

If I’m recalling yesterday’s presentation correctly, it was ARIN Staff and 
Legal, not the AC, that determined that this language could not be implemented 
an editorial change, so that’s not up for debate here.

One possible adjustment that I’d like to suggest is that the term “IPv4 and/or 
ASN resources” seems a bit awkward, given how many times it appears in the 
section. Perhaps we could add a new section that incorporates David’s suggested 
language, but also handles the clarification of the definition of number 
resources in a single place, scoped to Section 8.

So, a new Section 8.1.1, which I’d propose would be named “Definitions”, could 
read as follows:


All references to “number resources" in this section, unless stated 
otherwise, refer to IPv4 addresses and/or ASN resources. 

When number resources of multiple types, including IPv6 resources, are 
transferred, each resource type is considered separately and independently, 
both for any conditions on their transferability and the application of any 
restrictions following a transfer.


Following this, the other edits to Section 8 in the proposal can simply be 
changed to “number resources” to suit.

Opinions?

-C


> On Oct 21, 2021, at 11:23 AM, Martin Hannigan  wrote:
> 
> 
> I agree with Owen re: the editorial nature of the changes. However, I support 
> it moving forward. I don't support the Farmer suggestion. That is possibly a 
> material change that should undergo the rigors of "the process" on its own.
> 
> Warm regards,
> 
> -M<
> 
> 
> 
> 
> 
> On Thu, Oct 21, 2021 at 11:33 AM Owen DeLong via ARIN-PPML 
> mailto:arin-ppml@arin.net>> wrote:
> I support this amendment.
> 
> Owen
> 
> 
>> On Oct 20, 2021, at 12:45 , David Farmer via ARIN-PPML > > wrote:
>> 
>> I support this proposal as currently written. 
>> 
>> However, regarding Kevin Blumberg's comment at the ARIN 48 discussion of 
>> this policy earlier today; How about adding a paragraph like the following 
>> to section 8.1, Principles;
>> 
>> When number resources of multiple types, IPv4, IPv6, and/or ASNs, are 
>> transferred, each resource type is considered separately and independently, 
>> both for any conditions on their transferability and the application of any 
>> restrictions following a transfer.
>> 
>> Something like this added to Section 8.1, Principles, along with the already 
>> proposed changes should eliminate any possibility of confusion in this 
>> regard.
>> 
>> Thanks
>> 
>> On Tue, Aug 24, 2021 at 7:52 AM ARIN mailto:i...@arin.net>> 
>> 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 

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

[Chris Woodfield]

Side note worth pointing out - candidates added to the ballot via a successful 
petition are saddled with one distinct disadvantage, in that they have a much 
shorter window in which to garner Statements Of Support than the candidates on 
the initial slate.

As such, if you support either of these candidates, I would recommend taking 
advantage of the remaining time to submit your statement.

Thanks,

-C

> On Oct 19, 2021, at 2:17 PM, Mike Burns  wrote:
> 
> Hi John,
>  
> Those were discrete, non-controversial and easily digestible suggestions, but 
> this situation is much larger in scope and difficulty, IMO. Rather than a 
> single comment, this issue needs public debate IMO.
>  
> Regards,
> Mike
>  
>  
> From: ARIN-PPML  On Behalf Of John Curran
> Sent: Tuesday, October 19, 2021 4:49 PM
> To: Martin J Hannigan 
> Cc: arin-ppml@arin.net
> Subject: Re: [arin-ppml] ARIN Announces the Final Slate of Candidates for the 
> 2021 ARIN Elections
>  
> Marty -  
>  
>> To be clear, two of those suggestions directly led to changes similar to 
>> those requested (changes to ARIN Board of Trustee agenda and minutes 
>> practices, and inclusion of a non-incumbent on Board of Trustee election 
>> slates.) – i.e. the ASCP process does result in suggestions being considered 
>> by the Board of Trustees, and can often result in change.
>  
> Thanks!
> /John
>  
> John Curran
> President and CEO
> American Registry for Internet Numbers
>  
>> On 19 Oct 2021, at 3:44 PM, Martin Hannigan > > wrote:
>>  
>>  
>>  
>> Hi John,
>>  
>> Doesn't seem suitable for the ASCP based on these responses:
>>  
>> https://www.arin.net/participate/community/acsp/suggestions/2019/2019-8/ 
>> 
>> https://www.arin.net/participate/community/acsp/suggestions/2017/2017-27/ 
>> 
>> https://www.arin.net/participate/community/acsp/suggestions/2016/2016-14/ 
>> 
>> https://www.arin.net/participate/community/acsp/suggestions/2014/2014-20/ 
>> 
>>  
>> The ASCP seems most suitable for website improvements.
>>  
>> Warm regards,
>>  
>> -M<
>>  
>>  
>>  
>> On Tue, Oct 19, 2021 at 2:45 PM John Curran > > wrote:
>>> On 19 Oct 2021, at 2:07 PM, Mike Burns >> > wrote:
  
 I would also like to move forward. 
 How are such changes made, do we just hope the Board is floating above, 
 listening and maybe acting?
 Or is there a more formal process involved in governance process changes?
>>>  
>>> Mike - 
>>>  
>>> As I noted previously - 
>>>  
 To that end, I would strongly advise that immediately after this election 
 completes you submit whatever suggestions you have for improvement of 
 ARIN's elections to the ARIN suggestion and consultation process 
 > so that they 
 get formal consideration. 
  
>>> 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.

___
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-6: Remove Circuit Requirement

[Chris Woodfield]

Mike - 

The sample language I proposed was not intended to be interpreted as a proposed 
change to the ARIN RSA, but as a potential policy proposal. I do see how the 
current text could make that easy to misinterpret, and I’m happy to update the 
text to clarify as such.

Thanks,

-C

> On Sep 22, 2021, at 2:08 PM, Mike Burns  wrote:
> 
> The devil is in the details, and ARIN staff relies on clear guidance from the 
> community, which I feel your proposal lacks.
> What’s more I am not sure we can debate RSA changes on the PPML anyway.
> Is that allowed? I thought the RSA was the domain of the Board.
>  
> The entropy of the Internet tends to byzantine connections.
>  
> Regards,
> Mike
>  
>  
> From: Chris Woodfield  
> Sent: Wednesday, September 22, 2021 4:56 PM
> To: Mike Burns 
> Cc: PPML 
> Subject: Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement
>  
> I disagree. There are a number of other parts of the NRPM that explicitly 
> gives ARIN staff the discretion to consider whether or not a specific request 
> or allocation is in line with policy, and this discretion is put in place 
> specifically to avoid the sort of whack-a-mole (yes, I’m happy to keep using 
> that phrase) technical workaround arms race that would need to be engaged in 
> otherwise.
>  
> To your question as to whether a pencil-thin VPN would meet the test, that’s 
> exactly the question that this language gives ARIN staff the leeway to decide 
> or not. 
>  
> To put a bit more simply - intentions matter, and intentionally violating the 
> spirit of a policy should not be allowed by ARIN.
>  
> -C
> 
> 
>> On Sep 22, 2021, at 1:43 PM, Mike Burns > <mailto:m...@iptrading.com>> wrote:
>>  
>> Hi Chris,
>>  
>> If you are serious about your proposal, then yes, it’s important to consider 
>> every potential issue, and not serious to refer to them as whack-a-mole. 
>> That is what the policy development process is all about.
>>  
>> "No signatory to any ARIN RSA is permitted to issue addresses to customers 
>> who, in ARIN’s belief and discretion, are not contracting for a bona fide 
>> _network_ connectivity service _provided by the signatory_ that makes use of 
>> the allocated addresses"
>>  
>> So I can make assignments of my address space to other networks, who can 
>> then advertise and use them with their own connectivity. That sounds a lot 
>> like leasing in practice, if not funding.  Kind of hard to know who the 
>> customer actually is. Suppose I assign some of that pool to one of my 
>> customers via the cloud. So I am not connected to my customer at all, did I 
>> violate the RSA?
>>  
>> Of course you know a pencil-thin VPN would meet the test, but there are many 
>> more moles to whack.
>>  
>> Regards,
>> Mike
>>  
>>  
>>  
>> From: Chris Woodfield mailto:ch...@semihuman.com>> 
>> Sent: Wednesday, September 22, 2021 4:25 PM
>> To: Mike Burns mailto:m...@iptrading.com>>; PPML 
>> mailto:arin-ppml@arin.net>>
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement
>>  
>>  
>> 
>> 
>> 
>>> On Sep 22, 2021, at 1:12 PM, Mike Burns >> <mailto:m...@iptrading.com>> wrote:
>>>  
>>> (Back to this thread because I promised.)
>>>  
>>> Thanks for calling out an obvious bug, I should have noticed it myself. 
>>> Updated clause, changes bracketed by underlines:
>>>  
>>> "No signatory to any ARIN RSA is permitted to issue addresses to customers 
>>> who, in ARIN’s belief and discretion, are not contracting for a bona fide 
>>> _network_ connectivity service _provided by the signatory_ that makes use 
>>> of the allocated addresses"
>>>  
>>> -C
>>>  
>>> Say I am the registrant and I assign the block to my cloud provider to 
>>> advertise under their ASN and connectivity.
>>  
>> No, because the cloud provider is not your customer. 
>>  
>>> Did I violate the RSA?
>>> What if the cloud provider offers payment if I share my pool with other 
>>> users of that cloud network?
>>  
>> That would be an RSA violation, as at that point, the cloud provider *does* 
>> become your customer, that is purchasing the use of your address space, but 
>> not a connectivity service to them.
>>  
>> We can play the whack-a-mole game as long as you like, but the main point of 
>> the chosen language is that it gives ARIN staff the discretion to see 
>> through attempts at working 

Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement

[Chris Woodfield]

I disagree. There are a number of other parts of the NRPM that explicitly gives 
ARIN staff the discretion to consider whether or not a specific request or 
allocation is in line with policy, and this discretion is put in place 
specifically to avoid the sort of whack-a-mole (yes, I’m happy to keep using 
that phrase) technical workaround arms race that would need to be engaged in 
otherwise.

To your question as to whether a pencil-thin VPN would meet the test, that’s 
exactly the question that this language gives ARIN staff the leeway to decide 
or not. 

To put a bit more simply - intentions matter, and intentionally violating the 
spirit of a policy should not be allowed by ARIN.

-C

> On Sep 22, 2021, at 1:43 PM, Mike Burns  wrote:
> 
> Hi Chris,
>  
> If you are serious about your proposal, then yes, it’s important to consider 
> every potential issue, and not serious to refer to them as whack-a-mole. That 
> is what the policy development process is all about.
>  
> "No signatory to any ARIN RSA is permitted to issue addresses to customers 
> who, in ARIN’s belief and discretion, are not contracting for a bona fide 
> _network_ connectivity service _provided by the signatory_ that makes use of 
> the allocated addresses"
>  
> So I can make assignments of my address space to other networks, who can then 
> advertise and use them with their own connectivity. That sounds a lot like 
> leasing in practice, if not funding.  Kind of hard to know who the customer 
> actually is. Suppose I assign some of that pool to one of my customers via 
> the cloud. So I am not connected to my customer at all, did I violate the RSA?
>  
> Of course you know a pencil-thin VPN would meet the test, but there are many 
> more moles to whack.
>  
> Regards,
> Mike
>  
>  
>  
> From: Chris Woodfield  
> Sent: Wednesday, September 22, 2021 4:25 PM
> To: Mike Burns ; PPML 
> Subject: Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement
>  
>  
> 
> 
>> On Sep 22, 2021, at 1:12 PM, Mike Burns > <mailto:m...@iptrading.com>> wrote:
>>  
>> (Back to this thread because I promised.)
>>  
>> Thanks for calling out an obvious bug, I should have noticed it myself. 
>> Updated clause, changes bracketed by underlines:
>>  
>> "No signatory to any ARIN RSA is permitted to issue addresses to customers 
>> who, in ARIN’s belief and discretion, are not contracting for a bona fide 
>> _network_ connectivity service _provided by the signatory_ that makes use of 
>> the allocated addresses"
>>  
>> -C
>>  
>> Say I am the registrant and I assign the block to my cloud provider to 
>> advertise under their ASN and connectivity.
>  
> No, because the cloud provider is not your customer. 
>  
>> Did I violate the RSA?
>> What if the cloud provider offers payment if I share my pool with other 
>> users of that cloud network?
>  
> That would be an RSA violation, as at that point, the cloud provider *does* 
> become your customer, that is purchasing the use of your address space, but 
> not a connectivity service to them.
>  
> We can play the whack-a-mole game as long as you like, but the main point of 
> the chosen language is that it gives ARIN staff the discretion to see through 
> attempts at working around any sort of technical definition of an address 
> lease, and call out the practice for what it is, no matter how the 
> organization attempts to claim otherwise via an increasingly-byzantine 
> technical structure.
>  
> -C
> 
> 
>>  
>> Regards,
>> Mike
>>  
>>  
>> From: ARIN-PPML > <mailto:arin-ppml-boun...@arin.net>> On Behalf Of Mike Burns
>> Sent: Wednesday, September 22, 2021 11:50 AM
>> To: 'Chris Woodfield' mailto:ch...@semihuman.com>>; 
>> 'PPML' mailto:arin-ppml@arin.net>>
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement
>>  
>> Hi Chris,
>>  
>> I am still unclear. So the “risk” you refer to is the inability to purchase 
>> new blocks using leases as justification?
>> I’m not entirely sure how that constitutes a risk, unless you mean they will 
>> run out of addresses they need for themselves. Is that their risk?
>>  
>> It seems like you are objecting to a proposal to allow using leased 
>> addresses as justification by simply stating that you don’t like leasing.
>>  
>> Why can’t you stand behind this distribution method, can you be clear on 
>> your objection to leasing?
>> Because certainly this proposal facilitates leasing.
>>  
>> I guess we are coming to the crux of things now, I’ve

Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement

[Chris Woodfield]

> On Sep 22, 2021, at 1:12 PM, Mike Burns  wrote:
> 
> (Back to this thread because I promised.)
>  
> Thanks for calling out an obvious bug, I should have noticed it myself. 
> Updated clause, changes bracketed by underlines:
>  
> "No signatory to any ARIN RSA is permitted to issue addresses to customers 
> who, in ARIN’s belief and discretion, are not contracting for a bona fide 
> _network_ connectivity service _provided by the signatory_ that makes use of 
> the allocated addresses"
>  
> -C
>  
> Say I am the registrant and I assign the block to my cloud provider to 
> advertise under their ASN and connectivity.

No, because the cloud provider is not your customer. 

> Did I violate the RSA?
> What if the cloud provider offers payment if I share my pool with other users 
> of that cloud network?

That would be an RSA violation, as at that point, the cloud provider *does* 
become your customer, that is purchasing the use of your address space, but not 
a connectivity service to them.

We can play the whack-a-mole game as long as you like, but the main point of 
the chosen language is that it gives ARIN staff the discretion to see through 
attempts at working around any sort of technical definition of an address 
lease, and call out the practice for what it is, no matter how the organization 
attempts to claim otherwise via an increasingly-byzantine technical structure.

-C

>  
> Regards,
> Mike
>  
>  
> From: ARIN-PPML  On Behalf Of Mike Burns
> Sent: Wednesday, September 22, 2021 11:50 AM
> To: 'Chris Woodfield' ; 'PPML' 
> Subject: Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement
>  
> Hi Chris,
>  
> I am still unclear. So the “risk” you refer to is the inability to purchase 
> new blocks using leases as justification?
> I’m not entirely sure how that constitutes a risk, unless you mean they will 
> run out of addresses they need for themselves. Is that their risk?
>  
> It seems like you are objecting to a proposal to allow using leased addresses 
> as justification by simply stating that you don’t like leasing.
>  
> Why can’t you stand behind this distribution method, can you be clear on your 
> objection to leasing?
> Because certainly this proposal facilitates leasing.
>  
> I guess we are coming to the crux of things now, I’ve asked a few people who 
> have opposed this policy why, and for some it comes down to disapproving of 
> leasing. Now I’ve asked why.
>  
> A good reason, to me, is that leasing often serves the needs of miscreants. 
> But leasing is allowed, so miscreants are currently being served. My 
> experience tells me that miscreants have the advantage over most incumbent 
> lessors, who are generally not in the business of leasing addresses. 
>  
> ARIN policy prevents newcomers into the leasing business, and I think 
> professional lessors will provide some balance against miscreants if they 
> were allowed to enter that market. 
>  
> Regards,
> Mike
>  
>  
>  
>  
>  
>  
> From: Chris Woodfield mailto:ch...@semihuman.com>> 
> Sent: Wednesday, September 22, 2021 11:33 AM
> To: PPML mailto:arin-ppml@arin.net>>
> Cc: Owen DeLong mailto:o...@delong.com>>; Mike Burns 
> mailto:m...@iptrading.com>>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement
>  
> I’m speaking to the risk that an organization that engages in leasing address 
> blocks without providing related connectivity services. Given that these 
> blocks cannot currently be used as justification for additional space, an 
> organization that does so would not qualify for additional space should they 
> require it, unless they are falsifying the nature of the allocations in their 
> justification documentation (which, of course, is a policy violation that 
> could lead to that organizations’s allocations being reclaimed if discovered).
>  
> This policy proposal, per the problem statement, is explicitly aimed at 
> removing that risk, and as such, putting ARIN’s stamp of approval on this 
> type of lease practice, and in fact, allows organizations to require 
> additional space which it could then lease out, without the need to provide 
> the network services associated with the blocks being leased. Which is a type 
> of IP block monetization that I simply cannot stand behind.
>  
> As such, I remain opposed to this proposal.
>  
> -C
>  
> 
>> On Sep 22, 2021, at 7:00 AM, Mike Burns > <mailto:m...@iptrading.com>> wrote:
>>  
>> Hi Chris,
>>  
>> Can you be more specific on which inherent risk this policy would remove?
>> Somebody +1’d this, but I don’t understand what you mean.
>> I don’t even know which party’

Re: [arin-ppml] Proposal to ban Leasing of IP Addresses in the ARIN region

[Chris Woodfield]

On Sep 22, 2021, at 11:45 AM, Mike Burns  wrote:
> 
> "No signatory to any ARIN RSA is permitted to issue addresses to customers 
> who, in ARIN’s belief and discretion, are not contracting for a bona fide 
> connectivity service that makes use of the allocated addresses.”
> 
> Does that sound unreasonable?
> 
> -C
> 
> Hi Chris,
> 
> Have you considered that every lessee contracts for connectivity service 
> somewhere in order to use the allocated addresses?
> 
> So I can lease my addresses to my lessees, they connect to another network 
> via BGP and advertise my block under their ASN. How would that affect your 
> proposed change to the RSA? Those using the addresses have in fact contracted 
> for the bona fide connectivity service your language requires.
> 

Thanks for calling out an obvious bug, I should have noticed it myself. Updated 
clause, changes bracketed by underlines:

"No signatory to any ARIN RSA is permitted to issue addresses to customers who, 
in ARIN’s belief and discretion, are not contracting for a bona fide _network_ 
connectivity service _provided by the signatory_ that makes use of the 
allocated addresses"

-C

> Regards,
> Mike
> PS Sorry John and Michael, I saw you emails and this will be the last post to 
> this thread.
> 
> 
> Sounds like the whoosh of addresses from ARIN to RIPE.
> Or a bunch of little vpn tunnels bubbling up.
> Many cloud providers allow for clients to bring their own addresses and use 
> them on the cloud network.
> So the addresses are being advertised by an ASN which is not associated with 
> the address owner.
> This is the practice of leasing, blocks advertised through other parties' 
> networks.
> Every lessee has connectivity service that makes use of the allocated 
> addresses, how else would they be used?
> 
> 
> 
> 
> -Original Message-
> From: ARIN-PPML  On Behalf Of Chris Woodfield
> Sent: Wednesday, September 22, 2021 2:25 PM
> To: William Herrin 
> Cc: PPML 
> Subject: Re: [arin-ppml] Proposal to ban Leasing of IP Addresses in the ARIN 
> region
> 
> 
> 
>> On Sep 22, 2021, at 10:19 AM, William Herrin  wrote:
>> 
>> 
>> 
>> Hi Chris,
>> 
>> As I noted in a recent thread, there's no language you can write which 
>> will prevent that from happening. The service provider can just bump 
>> it one step further back. "Oh, we can't provide a VPN? Okay, we don't.
>> We do BGP with the customer's virtual server and what they do with it 
>> is not for us to say. Oh, we can't provide the virtual server or have 
>> to police the customer's use?Tell that to Amazon before you hassle us.
>> Good luck."
>> 
>> However, just because we can't prevent something doesn't mean we have 
>> to legitimize it and make it easy for the folks who want to be 
>> high-price mini-ARINs. And if the status quo has become unstable due 
>> to the price of IP addresses, I'd rather see the policy moved away 
>> from leasing addresses for use with BGP rather than moved toward it.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> --
>> William Herrin
>> b...@herrin.us
>> https://bill.herrin.us/
>> 
> 
> Thinking more on this, I don’t disagree. It may be very much the case that 
> any attempt to technically define the type of practice such a policy is 
> intended to discourage - despite everyone having a similar mental model of 
> what that practice is - is doomed to an arms race of technical workarounds 
> and fig leaves.
> 
> As such, I’m wondering if the language we’re looking for may not be technical 
> language, but in fact legal language. If you’ll forgive the anecdote, I’m in 
> the process of buying a new car, and I noticed language that gives the dealer 
> the right to cancel the sale if the dealer believes that it is being made 
> “with an eye towards resale, or otherwise in bad faith”. This, IMO is fuzzy 
> enough that it gives the dealer quite a bit of discretion to see through 
> technical workarounds, while keeping organizations that are not engaged in 
> leasing reasonably safe from finding themselves on the wrong side of a 
> technical definition of the practice.
> 
> Modifying Fernando’s suggested language, I’d think something like the 
> following could be viable:
> 
> "No signatory to any ARIN RSA is permitted to issue addresses to customers 
> who, in ARIN’s belief and discretion, are not contracting for a bona fide 
> connectivity service that makes use of the allocated addresses.”
> 
> Does that sound unreasonable?
> 
> -C
> ___
> ARIN-PPML
> You are receiving this message because you a

Re: [arin-ppml] Proposal to ban Leasing of IP Addresses in the ARIN region

[Chris Woodfield]

> On Sep 22, 2021, at 10:19 AM, William Herrin  wrote:
> 
> 
> 
> Hi Chris,
> 
> As I noted in a recent thread, there's no language you can write which
> will prevent that from happening. The service provider can just bump
> it one step further back. "Oh, we can't provide a VPN? Okay, we don't.
> We do BGP with the customer's virtual server and what they do with it
> is not for us to say. Oh, we can't provide the virtual server or have
> to police the customer's use?Tell that to Amazon before you hassle us.
> Good luck."
> 
> However, just because we can't prevent something doesn't mean we have
> to legitimize it and make it easy for the folks who want to be
> high-price mini-ARINs. And if the status quo has become unstable due
> to the price of IP addresses, I'd rather see the policy moved away
> from leasing addresses for use with BGP rather than moved toward it.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
> 

Thinking more on this, I don’t disagree. It may be very much the case that any 
attempt to technically define the type of practice such a policy is intended to 
discourage - despite everyone having a similar mental model of what that 
practice is - is doomed to an arms race of technical workarounds and fig leaves.

As such, I’m wondering if the language we’re looking for may not be technical 
language, but in fact legal language. If you’ll forgive the anecdote, I’m in 
the process of buying a new car, and I noticed language that gives the dealer 
the right to cancel the sale if the dealer believes that it is being made “with 
an eye towards resale, or otherwise in bad faith”. This, IMO is fuzzy enough 
that it gives the dealer quite a bit of discretion to see through technical 
workarounds, while keeping organizations that are not engaged in leasing 
reasonably safe from finding themselves on the wrong side of a technical 
definition of the practice.

Modifying Fernando’s suggested language, I’d think something like the following 
could be viable:

"No signatory to any ARIN RSA is permitted to issue addresses to customers who, 
in ARIN’s belief and discretion, are not contracting for a bona fide 
connectivity service that makes use of the allocated addresses.”

Does that sound unreasonable?

-C
___
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] Proposal to ban Leasing of IP Addresses in the ARIN region

[Chris Woodfield]

Fernando - I would support language similar to what you’ve proposed, as it 
explicitly requires the address allocation to be part of a connectivity service.

The trick then would be to make sure organizations can’t do it the other way 
around; I’m reminded of a nightclub I used to frequent that held a restaurant 
license, which only allowed them to serve alcohol as part of a order for food. 
As such, customers did not order drinks, they would buy a packet of peanuts 
that happened to be served with an alcoholic beverage alongside.

Let’s make sure that with this language, we don’t suddenly see an influx of 
“VPN Providers” who happen to be routing /24 or larger blocks to each of their 
customer’s tunnels.

Thanks,

-Chris 

> On Sep 22, 2021, at 9:12 AM, Fernando Frediani  wrote:
> 
> I believe maybe Michael didn't understand well the matter fully or got only 
> part of it.
> Probably what caused more confusion was how Owen put the part "No signatory 
> to any ARIN RSA is permitted by policy to engage in a recurring charge for 
> addresses or a differentiated service charge based on the number if addresses 
> issued to a customer.". That could be dubious in the sense that a LIR could 
> not charge administrative fees when they assign addresses to their 
> connectivity customers.
> 
> A simple: "No signatory to any ARIN RSA is permitted by policy to engage 
> issuing addresses to non-conectivity customers. Addresses must be provided 
> strictly as part of a contract for connectivity services."
> 
> I think Owen tried to put in a way to strengthen his point of view the LIR 
> lease addresses and by that text they would not permitted to do even for 
> connectivity customers.Simplifying it would achieve the objective in the 
> subject without necessarily change the usual way LIRs allocate addresses to 
> their *connectivity customers*.
> 
> Regards
> Fernando
> 
> On 22/09/2021 13:00, Isaiah Olson wrote:
>> Hi Michael, 
>> 
>> I appreciate you clarifying this issue. If this policy proposal is 
>> considered out of scope, I would ask why Mike's policy proposal to 
>> explicitly allow leasing is considered in-scope for this PDP? If it is 
>> ARIN's position that it "does not impose any such restrictions on trade or 
>> pricing" with regards to pricing structure, why does ARIN differentiate 
>> justified need for transfers (trade) based on the absence or presence of 
>> connectivity services? 
>> 
>> I am happy to dispatch with any discussions that are not relevant or 
>> allowed, but I think that your post requires additional clarification of 
>> what topics are not permissible since many of the issues you have raised as 
>> out of scope are germane to other policies under discussion. 
>> 
>> Thanks, 
>> Isaiah 
>> 
>> ___ 
>> 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 ARIN-2021-6: Remove Circuit Requirement

[Chris Woodfield]

I believe that IP resources are a public good, and as such, must be managed in 
a way that is equitable as practically possible. 

For 30+ years, before the existence of ARIN - a cornerstone of equitable 
management of this particular public good has been that IP blocks should be 
registered by operators, and that organizations that hold allocations should be 
holding them because they have an operational need for them to run their and/or 
their connectivity customer’s networks.

With this proposal in the NRPM, an entirely new type of LIR will be allowed to 
exist, one that does not operate a network and does not use the address space 
for its own needs, instead utilizing the allocated space purely as a source of 
lease income. Even more so, that type of organization has multiple business 
benefits: it can officially hold address allocations whose transfer value is 
virtually guaranteed to go up over time, while at the same time earning income 
via leases. Sounds like a great business opportunity, to be honest.

However, I fear that such organizations will create severe distortions in the 
transfer market, as these organizations will be able to acquire resources with 
virtually no limit to their holdings, and will be able to acquire new space as 
quickly as they’re able to lease it out. Thus, those who wish to obtain their 
own addresses will find doing so increasingly difficult and expensive, and will 
find themselves with little choice but to... lease addresses from this type of 
organization. Thus furthering the extent of the market distortion.

In many other business, we refer to this as “rent seeking”, and is not looked 
upon favorably.

Hopefully, this sufficiently explains why I “don’t like leasing”. 

Thanks,

-Chris

> On Sep 22, 2021, at 8:50 AM, Mike Burns  wrote:
> 
> Hi Chris,
>  
> I am still unclear. So the “risk” you refer to is the inability to purchase 
> new blocks using leases as justification?
> I’m not entirely sure how that constitutes a risk, unless you mean they will 
> run out of addresses they need for themselves. Is that their risk?
>  
> It seems like you are objecting to a proposal to allow using leased addresses 
> as justification by simply stating that you don’t like leasing.
>  
> Why can’t you stand behind this distribution method, can you be clear on your 
> objection to leasing?
> Because certainly this proposal facilitates leasing.
>  
> I guess we are coming to the crux of things now, I’ve asked a few people who 
> have opposed this policy why, and for some it comes down to disapproving of 
> leasing. Now I’ve asked why.
>  
> A good reason, to me, is that leasing often serves the needs of miscreants. 
> But leasing is allowed, so miscreants are currently being served. My 
> experience tells me that miscreants have the advantage over most incumbent 
> lessors, who are generally not in the business of leasing addresses. 
>  
> ARIN policy prevents newcomers into the leasing business, and I think 
> professional lessors will provide some balance against miscreants if they 
> were allowed to enter that market. 
>  
> Regards,
> Mike
>  
>  
>  
>  
>  
>  
> From: Chris Woodfield  
> Sent: Wednesday, September 22, 2021 11:33 AM
> To: PPML 
> Cc: Owen DeLong ; Mike Burns 
> Subject: Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement
>  
> I’m speaking to the risk that an organization that engages in leasing address 
> blocks without providing related connectivity services. Given that these 
> blocks cannot currently be used as justification for additional space, an 
> organization that does so would not qualify for additional space should they 
> require it, unless they are falsifying the nature of the allocations in their 
> justification documentation (which, of course, is a policy violation that 
> could lead to that organizations’s allocations being reclaimed if discovered).
>  
> This policy proposal, per the problem statement, is explicitly aimed at 
> removing that risk, and as such, putting ARIN’s stamp of approval on this 
> type of lease practice, and in fact, allows organizations to require 
> additional space which it could then lease out, without the need to provide 
> the network services associated with the blocks being leased. Which is a type 
> of IP block monetization that I simply cannot stand behind.
>  
> As such, I remain opposed to this proposal.
>  
> -C
> 
> 
>> On Sep 22, 2021, at 7:00 AM, Mike Burns > <mailto:m...@iptrading.com>> wrote:
>>  
>> Hi Chris,
>>  
>> Can you be more specific on which inherent risk this policy would remove?
>> Somebody +1’d this, but I don’t understand what you mean.
>> I don’t even know which party’s risk is being commented on.
>>  
>> Regards,

Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement

[Chris Woodfield]

I’m speaking to the risk that an organization that engages in leasing address 
blocks without providing related connectivity services. Given that these blocks 
cannot currently be used as justification for additional space, an organization 
that does so would not qualify for additional space should they require it, 
unless they are falsifying the nature of the allocations in their justification 
documentation (which, of course, is a policy violation that could lead to that 
organizations’s allocations being reclaimed if discovered).

This policy proposal, per the problem statement, is explicitly aimed at 
removing that risk, and as such, putting ARIN’s stamp of approval on this type 
of lease practice, and in fact, allows organizations to require additional 
space which it could then lease out, without the need to provide the network 
services associated with the blocks being leased. Which is a type of IP block 
monetization that I simply cannot stand behind.

As such, I remain opposed to this proposal.

-C

> On Sep 22, 2021, at 7:00 AM, Mike Burns  wrote:
> 
> Hi Chris,
>  
> Can you be more specific on which inherent risk this policy would remove?
> Somebody +1’d this, but I don’t understand what you mean.
> I don’t even know which party’s risk is being commented on.
>  
> Regards,
> Mike
>  
>  
> From: ARIN-PPML  On Behalf Of Chris Woodfield
> Sent: Tuesday, September 21, 2021 9:21 PM
> To: Owen DeLong 
> Cc: PPML 
> Subject: Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement
>  
>  
>> On Sep 21, 2021, at 10:22 AM, Owen DeLong > <mailto:o...@delong.com>> wrote:
>>  
>> This policy doesn’t affect that… Leasing of address space you already have 
>> is permitted under current policy and cannot be grounds for revocation of 
>> address space.
>>  
>> The change in this policy proposal is not to permit or deny leasing, but to 
>> permit leased addresses to be considered utilized for purposes of 
>> determining eligibility for additional address acquisition.
>>  
>  
> You are correct that the proposal may not permit or prohibit leasing, but it 
> does (intentionally, per the problem statement) remove one of the inherent 
> risks of the practice, and as such, in my view, is effectively an 
> endorsement. 
>  
> As such, my opposition stands.
>  
> -C
> 
> 
>> Owen
>>  
>> 
>> 
>>> On Sep 21, 2021, at 08:22 , Chris Woodfield >> <mailto:ch...@semihuman.com>> wrote:
>>>  
>>> Writing in opposition. I do not support the practice of leasing IP address 
>>> resources. Organizations who have received larger amounts of IP address 
>>> space than what they are efficiently utilizing are free to relieve 
>>> themselves of their excess space via the transfer market.
>>>  
>>> Thanks,
>>>  
>>> -Chris
>>> 
>>> 
>>>> On Sep 21, 2021, at 8:06 AM, ARIN mailto:i...@arin.net>> 
>>>> wrote:
>>>>  
>>>> On 16 September 2021, the ARIN Advisory Council (AC) accepted 
>>>> "ARIN-prop-302: Remove Circuit Requirement " as a Draft Policy.
>>>>  
>>>> Draft Policy ARIN-2021-6 is below and can be found at:
>>>>  
>>>> https://www.arin.net/participate/policy/drafts/2021_6/ 
>>>> <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 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/ 
>>>> <https://www.arin.net/participate/policy/pdp/>
>>>>  
>>>> Draft Policies and Proposals under discussion can be found at:
>>>> https://www.arin.net/participate/policy/drafts/ 
>>>> <https://www.arin.net/participate/policy/drafts/>
>>>>  
>>>> Regards,
>>>>  
>>>> Sean Hopkins
>>>> Senior Policy Analyst
>>>> American Registry for Internet Numbers (ARIN)
>>>>  
>>>>  
>>>> Draft Policy ARIN-2021-6: Remove Circuit Requirement 
>>>

Re: [arin-ppml] Draft Policy ARIN-2021-6: Remove Circuit Requirement

[Chris Woodfield]

> On Sep 21, 2021, at 10:22 AM, Owen DeLong  wrote:
> 
> This policy doesn’t affect that… Leasing of address space you already have is 
> permitted under current policy and cannot be grounds for revocation of 
> address space.
> 
> The change in this policy proposal is not to permit or deny leasing, but to 
> permit leased addresses to be considered utilized for purposes of determining 
> eligibility for additional address acquisition.
> 

You are correct that the proposal may not permit or prohibit leasing, but it 
does (intentionally, per the problem statement) remove one of the inherent 
risks of the practice, and as such, in my view, is effectively an endorsement. 

As such, my opposition stands.

-C

> Owen
> 
> 
>> On Sep 21, 2021, at 08:22 , Chris Woodfield > <mailto:ch...@semihuman.com>> wrote:
>> 
>> Writing in opposition. I do not support the practice of leasing IP address 
>> resources. Organizations who have received larger amounts of IP address 
>> space than what they are efficiently utilizing are free to relieve 
>> themselves of their excess space via the transfer market.
>> 
>> Thanks,
>> 
>> -Chris
>> 
>>> On Sep 21, 2021, at 8:06 AM, ARIN mailto:i...@arin.net>> 
>>> wrote:
>>> 
>>> On 16 September 2021, the ARIN Advisory Council (AC) accepted 
>>> "ARIN-prop-302: Remove Circuit Requirement " as a Draft Policy.
>>>  
>>> Draft Policy ARIN-2021-6 is below and can be found at:
>>>  
>>> https://www.arin.net/participate/policy/drafts/2021_6/ 
>>> <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 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/ 
>>> <https://www.arin.net/participate/policy/pdp/>
>>>  
>>> Draft Policies and Proposals under discussion can be found at:
>>> https://www.arin.net/participate/policy/drafts/ 
>>> <https://www.arin.net/participate/policy/drafts/>
>>>  
>>> Regards,
>>>  
>>> Sean Hopkins
>>> Senior Policy Analyst
>>> American Registry for Internet Numbers (ARIN)
>>>  
>>>  
>>> Draft Policy ARIN-2021-6: Remove Circuit Requirement 
>>>  
>>> Problem Statement:
>>>  
>>> Current ARIN policy prevents the use of leased-out addresses as evidence of 
>>> utilization.
>>>  
>>> Policy statement:
>>>  
>>> 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.”
>>>  
>>> 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 
>>> <mailto:ARIN-PPML@arin.net>).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml 
>>> <https://lists.arin.net/mailman/listinfo/arin-ppml>
>>> Please contact i...@arin.net <mailto: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 
>> <mailto:ARIN-PPML@arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml 
>> <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-6: Remove Circuit Requirement

[Chris Woodfield]

If you didn’t notice, my initial contribution to this subthread concluded with 
the sentence below:

"If you are an operator, ISP, or content provider who would benefit from this, 
I would recommend that you speak up in order to keep this proposal alive. “

I think that is exactly the definition of encouraging discussion. You’re free 
to disagree with my assessment, but you and I are not the scorekeepers here.

-C

> On Sep 21, 2021, at 5:03 PM, Mike Burns  wrote:
> 
> 
> It's been hours, Chris, and shouldn't you be encouraging discussion rather 
> than the opposite?
> 
> 
> Regards,
> Mike
> 
> 
> 
> 
>  On Tue, 21 Sep 2021 20:01:29 -0400 Chris Woodfield  
> wrote 
> 
> Given there was a proposal published last week that was withdrawn within 
> hours by its author*, I don’t think it’s unreasonable at all to start keeping 
> score WRT the level of community support on this one. And while the 
> definition of “strong support” is intentionally subjective, my four years 
> serving on the ARIN AC have informed my opinion that the current AC looks 
> for, at minimum, a lack of opposition from other segments of the community on 
> a proposal that appears to have the support of only one. A proposal supported 
> by the representatives of one segment, and by appearances so far, strongly 
> opposed by virtually everyone else, tend to have a rather short lifetime on 
> the AC docket.
> 
> -C
> 
> * Technically the author doesn’t withdraw a proposal, as it’s in the AC’s 
> hands once published. But in general, I would expect the AC to honor a 
> proposal author’s request to abandon it.
> 
> On Sep 21, 2021, at 3:48 PM, Mike Burns  wrote:
> 
> Hi Chris,
> 
> Not sure how experienced you are with this, but this proposal has only been 
> out for a few hours and any talk about "keeping it alive" is a tad early.
> 
> Also, you might brush up on the concept of ad hominem. It means against the 
> person(s). It could be only brokers who support a policy and if there are no 
> valid objections, that support should carry the day.
> 
> Now, do you have any objections that you would care to share, other than your 
> original one (which I think Owen dispensed with)?
> 
> Regards,
> Mike
> 
> 
> 
> 
>  On Tue, 21 Sep 2021 18:37:43 -0400 Chris Woodfield  
> wrote 
> 
> 
> 
> > On Sep 21, 2021, at 2:47 PM, Mike Burns  wrote: 
> > 
> > Hi Noah, 
> > 
> > Thanks for your thoughts, my replies are inline. 
> > 
> > “Transfers are generally a prerogative of brokers who don't necessarily 
> > provide any form of network services. It does make sense for a broker to 
> > defend this model.” 
> > 
> > Noah that is a meaningless ad hominem, every transfer has a recipient. 
> > 
> 
> You are not incorrect here - it takes two to tango, so to speak. And brokers 
> are an important segment of the ARIN community, to the extent that 
> representatives of IP brokers have been elected to the ARIN AC. 
> 
> That said, one of the requirements for a Draft Policy to move forward to an 
> RDP is, per section 4.3:, "Changes to policy must be shown to have a strong 
> level of support in the community in order to be adopted.” Reading the 
> replies to this thread so far, the only community members that have voiced 
> support for this proposal have been representatives of IP brokers. Correct me 
> if I’ve missed any, but I see zero statements of support so far from members 
> of any other segment of the ARIN community. 
> 
> I would be very surprised if the AC would advance to RDP a policy proposal 
> that has support of only one segment of the community, and as far as I can 
> tell, universal opposition from those who are not in that segment. If you are 
> an operator, ISP, or content provider who would benefit from this, I would 
> recommend that you speak up in order to keep this proposal alive. 
> 
> Thanks, 
> 
> -Chris 
> 
> > 
> > ___ 
> > 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-6: Remove Circuit Requirement

[Chris Woodfield]

Given there was a proposal published last week that was withdrawn within hours 
by its author*, I don’t think it’s unreasonable at all to start keeping score 
WRT the level of community support on this one. And while the definition of 
“strong support” is intentionally subjective, my four years serving on the ARIN 
AC have informed my opinion that the current AC looks for, at minimum, a lack 
of opposition from other segments of the community on a proposal that appears 
to have the support of only one. A proposal supported by the representatives of 
one segment, and by appearances so far, strongly opposed by virtually everyone 
else, tend to have a rather short lifetime on the AC docket.

-C

* Technically the author doesn’t withdraw a proposal, as it’s in the AC’s hands 
once published. But in general, I would expect the AC to honor a proposal 
author’s request to abandon it.

> On Sep 21, 2021, at 3:48 PM, Mike Burns  wrote:
> 
> Hi Chris,
> 
> Not sure how experienced you are with this, but this proposal has only been 
> out for a few hours and any talk about "keeping it alive" is a tad early.
> 
> Also, you might brush up on the concept of ad hominem. It means against the 
> person(s). It could be only brokers who support a policy and if there are no 
> valid objections, that support should carry the day.
> 
> Now, do you have any objections that you would care to share, other than your 
> original one (which I think Owen dispensed with)?
> 
> Regards,
> Mike
> 
> 
> 
> 
>  On Tue, 21 Sep 2021 18:37:43 -0400 Chris Woodfield  
> wrote 
> 
> 
> 
> > On Sep 21, 2021, at 2:47 PM, Mike Burns  > <mailto:m...@iptrading.com>> wrote: 
> > 
> > Hi Noah, 
> > 
> > Thanks for your thoughts, my replies are inline. 
> > 
> > “Transfers are generally a prerogative of brokers who don't necessarily 
> > provide any form of network services. It does make sense for a broker to 
> > defend this model.” 
> > 
> > Noah that is a meaningless ad hominem, every transfer has a recipient. 
> > 
> 
> You are not incorrect here - it takes two to tango, so to speak. And brokers 
> are an important segment of the ARIN community, to the extent that 
> representatives of IP brokers have been elected to the ARIN AC. 
> 
> That said, one of the requirements for a Draft Policy to move forward to an 
> RDP is, per section 4.3:, "Changes to policy must be shown to have a strong 
> level of support in the community in order to be adopted.” Reading the 
> replies to this thread so far, the only community members that have voiced 
> support for this proposal have been representatives of IP brokers. Correct me 
> if I’ve missed any, but I see zero statements of support so far from members 
> of any other segment of the ARIN community. 
> 
> I would be very surprised if the AC would advance to RDP a policy proposal 
> that has support of only one segment of the community, and as far as I can 
> tell, universal opposition from those who are not in that segment. If you are 
> an operator, ISP, or content provider who would benefit from this, I would 
> recommend that you speak up in order to keep this proposal alive. 
> 
> Thanks, 
> 
> -Chris 
> 
> > 
> > ___ 
> > ARIN-PPML 
> > You are receiving this message because you are subscribed to 
> > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> > <mailto:ARIN-PPML@arin.net>). 
> > Unsubscribe or manage your mailing list subscription at: 
> > https://lists.arin.net/mailman/listinfo/arin-ppml 
> > <https://lists.arin.net/mailman/listinfo/arin-ppml> 
> > Please contact i...@arin.net <mailto: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-6: Remove Circuit Requirement

[Chris Woodfield]

> On Sep 21, 2021, at 2:47 PM, Mike Burns  wrote:
> 
> Hi Noah, 
>  
> Thanks for  your thoughts, my replies are inline.
>  
> “Transfers are generally a prerogative of brokers who don't necessarily 
> provide any form of network services. It does make sense for a broker to 
> defend this model.”
>  
> Noah that is a meaningless ad hominem, every transfer has a recipient. 
>  

You are not incorrect here - it takes two to tango, so to speak. And brokers 
are an important segment of the ARIN community, to the extent that 
representatives of IP brokers have been elected to the ARIN AC.

That said, one of the requirements for a Draft Policy to move forward to an RDP 
is, per section 4.3:, "Changes to policy must be shown to have a strong level 
of support in the community in order to be adopted.” Reading the replies to 
this thread so far, the only community members that have voiced support for 
this proposal have been representatives of IP brokers. Correct me if I’ve 
missed any, but I see zero statements of support so far from members of any 
other segment of the ARIN community.

I would be very surprised if the AC would advance to RDP a policy proposal that 
has support of only one segment of the community, and as far as I can tell, 
universal opposition from those who are not in that segment. If you are an 
operator, ISP, or content provider who would benefit from this, I would 
recommend that you speak up in order to keep this proposal alive.

Thanks,

-Chris

>  
> ___
> 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-6: Remove Circuit Requirement

[Chris Woodfield]

Writing in opposition. I do not support the practice of leasing IP address 
resources. Organizations who have received larger amounts of IP address space 
than what they are efficiently utilizing are free to relieve themselves of 
their excess space via the transfer market.

Thanks,

-Chris

> On Sep 21, 2021, at 8:06 AM, ARIN  wrote:
> 
> On 16 September 2021, the ARIN Advisory Council (AC) accepted "ARIN-prop-302: 
> Remove Circuit Requirement " as a Draft Policy.
>  
> Draft Policy ARIN-2021-6 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 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-6: Remove Circuit Requirement 
>  
> Problem Statement:
>  
> Current ARIN policy prevents the use of leased-out addresses as evidence of 
> utilization.
>  
> Policy statement:
>  
> 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.”
>  
> 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] Proposal - Remove Initial Small Assignment Requirements for IPv6

[Chris Woodfield]

Don’t forget that IPv6 FIB entries, by nature, occupy more FIB space than IPv4, 
and an exponential increase in the size of the IPv6 table is far more likely to 
trash the TCAM of quite a number of larger providers’ backbone routers than a 
similar IPv4 route explosion. 

As such, I would expect representatives of the major hardware vendors to be 
very much in support of a proposal like this. Operators, not so much.

Thanks,

-Chris

> On Sep 13, 2021, at 8:37 PM, Sabri Berisha  wrote:
> 
> Hi,
> 
> - On Sep 13, 2021, at 12:40 PM, Larry R. Dockery 
> lrdoc...@co.douglas.or.us wrote:
> 
>> I am the proposal author and I will be withdrawing the proposal in light of 
>> the
>> routing issue.
> 
> Yes, the routing table is growing. But so has memory space. I was recently 
> involved
> in testing a widely available routing solution where we observed route 
> scaling well
> north of 3.5 million routes in hardware.
> 
> That will only increase in the future.
> 
> Thanks,
> 
> Sabri
> 
> 
> 
> 
> ___
> 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] Change of Use and ARIN (was: Re: AFRINIC And The Stability Of The Internet Number Registry System)

[Chris Woodfield]

Jordi - 

Correction noted, I erred in using the terms interchangeably. 
s/community/membership

For the record, ARIN’s PDP does explicitly empower the Board to reject or 
remand a Recommended Draft Policy that has reached community consensus: 
https://www.arin.net/participate/policy/pdp/#8-board-of-trustees-review 
<https://www.arin.net/participate/policy/pdp/#8-board-of-trustees-review> This 
is rare, but it has happened, with ARIN-2017-12 being the most recent example 
from my memory: 
https://lists.arin.net/pipermail/arin-ppml/2018-October/032593.html 

-C

> On Sep 7, 2021, at 12:39 PM, JORDI PALET MARTINEZ via ARIN-PPML 
>  wrote:
> 
> Unless I recall it incorrectly, they are elected by the *membership* not the 
> *community*. There is a huge difference.
>  
> In other regions, the chairs of the PDP are elected by the community. The 
> board is still elected by the membership, but the board has nothing to say in 
> regards to PDP/policy making process. Further to that, only one RIR (LACNIC) 
> has explicitly indicated in the PDP that the board could reject a policy that 
> reached consensus and return it to the policy list for further discussion. I 
> don’t think it happened ever – I agree that this is a good think in order to 
> protect the membership/organization if the community gets crazy, but it must 
> be clearly proven and explained with no doubts or signs of attempt of 
> community decisions manipulation.
>  
> AFRINIC board violated the PDP very recently by rejecting a policy that 
> reached consensus, while the AFRINIC PDP doesn’t allow that. It is almost a 
> clear “terrorist attack” towards the community. The irony is that this policy 
> was precisely allowing them to take urgent actions with policies in case of 
> “emergency situations” (which will need to reach consensus by the community 
> at the following meeting), which today is not allowed according to the PDP.
>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 7/9/21 20:04, "ARIN-PPML en nombre de Chris Woodfield" 
> mailto:arin-ppml-boun...@arin.net> en nombre de 
> ch...@semihuman.com <mailto:ch...@semihuman.com>> escribió:
>  
> Don’t forget the the ultimate say does, in fact, lie with the community, in 
> that the members of the Board and the Advisory Council are elected by the 
> community.
>  
> While there’s always the potential for a cynical take on the community’s 
> ability to affect meaningful change when needed, I’d hope that any egregious 
> policy decisions made by these bodies - decisions that the community agrees 
> are not in line with their collective interests - would result in the Board 
> and/or AC members responsible for those decisions having a much more 
> difficult time with their future re-election campaigns than they would 
> otherwise.
>  
> -Chris
> 
> 
>> On Sep 7, 2021, at 10:49 AM, Fernando Frediani > <mailto:fhfredi...@gmail.com>> wrote:
>>  
>> Hi Elvis
>>  
>> I have the same view as you do.
>> Despite this undertanding (and maybe the Board too - and correct me if I 
>> don't reproduce it accuratelly) I refuse the view that "PDP is a concession 
>> of the Board to the Community" and - this is what makes it even more 
>> controvertial - that 'this does not void ICP-2" due to historical reasons or 
>> whatever justification.
>>  
>> They are entiteled to their opinion but I do not believe that corrensponds 
>> to practical realitty.
>>  
>> I sincerelly hope that not only ARIN Board by any other RIR Board never void 
>> the bottom-up process and respect the ultimate power of community to choose 
>> how policies will be, not the Board unilaterally at their will.
>>  
>> Obviouslly this doesn't confuse with the prerrogative of the RIR Board to 
>> care about the organization protection and legal protection and I support 
>> that including the prerrogative of the Boards to ractify proposals that 
>> reached consensus.
>>  
>> Regards
>> Fernando
>>  
>> On Tue, 7 Sep 2021, 14:10 Elvis Daniel Velea, > <mailto:el...@velea.eu>> wrote:
>>> Hi,
>>> 
>>> 
>>>> On Sep 7, 2021, at 09:10, Owen DeLong via ARIN-PPML >>> <mailto:arin-ppml@arin.net>> wrote:
>>>> 
>>>>>> While the Board delegates the administration of policy development 
>>>>>> routinely to the ARIN AC, but it retains ultimate authority commensurate 
>>>>>> with the responsibility that they must bear for the organization.
>>>>  
>>>> This is a very useful clarification to have available for those who 
>>&g

Re: [arin-ppml] Change of Use and ARIN (was: Re: AFRINIC And The Stability Of The Internet Number Registry System)

[Chris Woodfield]

Don’t forget the the ultimate say does, in fact, lie with the community, in 
that the members of the Board and the Advisory Council are elected by the 
community.

While there’s always the potential for a cynical take on the community’s 
ability to affect meaningful change when needed, I’d hope that any egregious 
policy decisions made by these bodies - decisions that the community agrees are 
not in line with their collective interests - would result in the Board and/or 
AC members responsible for those decisions having a much more difficult time 
with their future re-election campaigns than they would otherwise.

-Chris

> On Sep 7, 2021, at 10:49 AM, Fernando Frediani  wrote:
> 
> Hi Elvis
> 
> I have the same view as you do.
> Despite this undertanding (and maybe the Board too - and correct me if I 
> don't reproduce it accuratelly) I refuse the view that "PDP is a concession 
> of the Board to the Community" and - this is what makes it even more 
> controvertial - that 'this does not void ICP-2" due to historical reasons or 
> whatever justification.
> 
> They are entiteled to their opinion but I do not believe that corrensponds to 
> practical realitty.
> 
> I sincerelly hope that not only ARIN Board by any other RIR Board never void 
> the bottom-up process and respect the ultimate power of community to choose 
> how policies will be, not the Board unilaterally at their will.
> 
> Obviouslly this doesn't confuse with the prerrogative of the RIR Board to 
> care about the organization protection and legal protection and I support 
> that including the prerrogative of the Boards to ractify proposals that 
> reached consensus.
> 
> Regards
> Fernando
> 
> On Tue, 7 Sep 2021, 14:10 Elvis Daniel Velea,  > wrote:
> Hi,
> 
>> On Sep 7, 2021, at 09:10, Owen DeLong via ARIN-PPML > > wrote:
>> 
>>> While the Board delegates the administration of policy development 
>>> routinely to the ARIN AC, but it retains ultimate authority commensurate 
>>> with the responsibility that they must bear for the organization.
>> 
>> This is a very useful clarification to have available for those who continue 
>> to argue that the community is the ultimate authority on policy matters. 
>> Thank you.
> 
> Very surprised to see John explain how the bottom-up process works (or not) 
> in ARIN and how much influence the ARIN Board has on policy.
> 
> I am also extremely surprised to see the difference in PDP between ARIN and 
> the rest of the RIRs as per John’s statement above.
> 
> Elvis
> 
> 
> ___
> 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] Change of Use and ARIN (was: Re: AFRINIC And The Stability Of The Internet Number Registry System)

[Chris Woodfield]

David - 

In addition to the RSA language John cited, Section 12 of the NRPM gives ARIN 
the right to review an organization’s resource usage at any time for continued  
compliance with community-driven policy. I suspect that these reviews are not 
common, however. What’s more common, in my view, is an organization’s request 
for additional resources, which must come with justification that 
currently-held resources are being used in compliance with policy. I do not 
believe that these are checked against the original requests for consistency, 
however.

I’d be curious if the clause below can be interpreted as giving organizations a 
duty to report *any* substantial changes in an organization’s allocation plans 
if they diverge from the justification filed at the time of the request, or 
only when such changes would have the effect of putting the organization out of 
compliance with current policy. I can see the former interpretation being 
rather troublesome for a large number of organizations, given how often 
business plans and environments can change over time, as well as adding quite a 
bit of (IMO unnecessary) overhead to IP allocation managers.

That said, I can see ARIN being quite justified in reclaiming resources if the 
justification documentation filed with the request had no bearing to the org’s 
actual plans. I suspect that to be the unspoken subtext of the current 
controversy, and I absolutely believe that ARIN would and should act similarly 
in such a scenario (which, in the past, it has).

Regards,,

-Chris

> On Sep 1, 2021, at 1:21 PM, John Curran  wrote:
> 
> David - 
> 
> Excellent question.   The most important item is for the community to 
> determine its policy goals in this area, and then based on such what 
> requirements/duties belong in policy language in Number Resource Policy 
> Manual (NRPM.)
> 
> The ARIN RSA places an explicit duty of “Information and Cooperation” on 
> number resource holders (see below) that can be used to enforce 
> community-developed policy in this area, but the communities thoughts on the 
> appropriate policy really should drive the discussion – 
> 2.(c) Information and Cooperation. Holder has completed an application 
> provided by ARIN for one or more Services (the “Application”). Holder must 
> (i) promptly notify ARIN if any information provided in the Application 
> changes during the term of this Agreement, and (ii) make reasonable efforts 
> to promptly, accurately, and completely provide any information or 
> cooperation required pursuant to the Service Terms or in response to any 
> inquiry or request made to Holder by ARIN during the term of this Agreement. 
> In addition, Holder shall promptly provide ARIN with complete and accurate 
> information, and cooperation as required by any Service Terms or that ARIN 
> requests in connection with ARIN’s provision of any of the Services to 
> Holder. If Holder does not provide ARIN with such information or cooperation 
> that ARIN requests, ARIN may take such failure into account in evaluating 
> Holder’s subsequent requests for transfer, allocation or assignment of 
> additional number resources, or requests for changes to any Services. 
> 
> Note that material breach of Section 2(c) is one of the events that provides 
> ARIN clear right of termination for the RSA and subsequent revocation of the 
> number resources – so let’s be extra careful when considering any 
> reporting/information duties for placement into NRPM. 
> 
> Thanks! 
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 
> 
> On 1 Sep 2021, at 3:47 PM, David Farmer  > wrote:
>> 
>> I changed the subject line, as this isn't directly related to the dispute 
>> between AFRINIC and CI, but more some questions arising from it specifically 
>> related to the ARIN registered resources.
>> 
>> 
>> So, do ARIN resource holders have a duty to report changes in their use of 
>> resources? If they do, where does that duty come from in policy or contract 
>> language? And, what are the relevant changes that need to be reported?
>> 
>> In my review of these questions;
>> 
>> In the RSA I see where holders are granted, "The right to use the Included 
>> Number Resources within the ARIN database" (RSA section 2.b bullet 2). 
>> However, I don't see any limitation to that use, such as "originally 
>> justified" or any obligation to report a change in such use.
>> 
>> In policy, "An end-user is an organization receiving assignments of IP 
>> addresses exclusively for use in its operational networks." (NRPM 2.6), with 
>> an exception for incidental or transient use (last paragraph, section 2.5).
>> 
>> Maybe to align end-user requirements with the new Registration Services 
>> Agreement we should change that so end-users have to report any use, other 
>> than incidental or transient use, outside their organization.
>> 
>> And ISP's have requirements to report the use by their 

Re: [arin-ppml] Updated text: ARIN 2020-6 Swap Policy

[Chris Woodfield]

Inline:

> On Aug 26, 2021, at 10:46 AM, Mike Burns  wrote:
> 
> Hi,
> 
> I think the larger block should be allowed to be sold in pieces, 
> notwithstanding the disaggregation.

The intent of this policy is to allow organizations to avoid deaggregation, and 
contributing to global BGP table bloat, by transferring a smaller block in, 
then a larger block out in one piece. If the policy allows selling the larger 
block in pieces, that’s really no different than if they simply renumbered into 
a smaller portion of it and sold off the rest, making this policy language more 
or less pointless IMO.

> 
> I think the recipient should lose the ability to receive addresses 
> immediately upon receipt of the smaller block, until the larger block is 
> completely sold. Including waitlist addresses, not included other reserved 
> addresses.

After my last email, I did think of a corner case this might bite an 
otherwise-trying-to-do-the-right-thing operator: they transfer in, say, a /24, 
but grow faster than expected and need a second /24 (or larger block) before 
they can get rid of the block they’re seeking to transfer. As such, I rescind 
my earlier mention of this as a potential change I’d support.

> 
> If the smaller block is a /24, there should be no needs test.

Agreed, but I think this is already covered in other language? Does it need to 
be repeated here if so?

> I would lose the officer attestation.

My assumption is that this needs to be in place currently, as it is with other 
sections regarding needs-based requests; once the consultation is done, if the 
result of that process is to remove, I expect an omnibus proposal to be 
authored removing the language wherever it exists.

Thanks,

-C

> 
> Regards,
> Mike 
> 
> 
> 
> 
> -Original Message-
> From: ARIN-PPML  On Behalf Of Chris Woodfield
> Sent: Thursday, August 26, 2021 1:09 PM
> To: ARIN-PPML List 
> Subject: Re: [arin-ppml] Updated text: ARIN 2020-6 Swap Policy
> 
> This new language has my support, with a few comments:
> 
> - If I’m reading this properly, the prohibition on transferring the smaller 
> block kicks in if the larger block isn’t transferred within a year. Have we 
> considered the option of having that restriction kick in immediately until 
> the larger block is transferred? Or was that considered too onerous?
> 
> - I’ve noticed that officer attestation language is present in the new 
> 8.5.5.1.1 subsection; I’m assuming this will remain in place despite the 
> separate discussion on removing the need for officer attestations, and 
> removed via a future policy proposal if that action is taken. Please advise 
> if that assumption is incorrect.
> 
> Thanks,
> 
> -C
> 
>> On Aug 26, 2021, at 6:54 AM, Rob Seastrom  wrote:
>> 
>> 
>> Dear ARIN Community,
>> 
>> Please read the updated text for policy proposal ARIN 2020-6 Swap Policy 
>> (below) and offer your thoughts and comments.
>> 
>> All the best,
>> 
>> -r
>> 
>> -=-=-=-=-
>> 
>> ARIN 2020-6 Swap Policy
>> 
>> Current text:
>> 
>> 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.
>> 
>> 
>> Add:
>> 
>> 8.5.5.1- Transfer for the Purpose of Renumbering Organizations with 
>> larger direct allocations or assignments than they require may receive 
>> transfer of a smaller block for the purpose of renumbering onto the smaller 
>> block if they transfer the entire larger block to a qualified recipient 
>> under section 8 within one year of receipt of transfer of the smaller block. 
>> If the larger block is not transferred within one year of receipt of the 
>> smaller block, the smaller block will be ineligible for transfer under 
>> sections 8.3 and 8.4, and the organization will be ineligible to receive any 
>> further transfers under this policy.
>> 
>>  8.5.5.1.1 Smaller Block Size
>>  Organizations may qualify to receive transfer of a smaller block by 
>> providing documentation to ARIN which details the use of at least 50% 
>> of the smaller block size within 24 months. Current use of the larger 
>> block may be used to satisfy this criteria. An officer of the 
>> organization shall attest to the documentation provided to ARIN
>> 
>> Current text:
>> 8.5.6. Efficient Utilization of Previous Blocks Organizations with 
>> direct assignments or allocations fro

Re: [arin-ppml] Updated text: ARIN 2020-6 Swap Policy

[Chris Woodfield]

This new language has my support, with a few comments:

- If I’m reading this properly, the prohibition on transferring the smaller 
block kicks in if the larger block isn’t transferred within a year. Have we 
considered the option of having that restriction kick in immediately until the 
larger block is transferred? Or was that considered too onerous?

- I’ve noticed that officer attestation language is present in the new 
8.5.5.1.1 subsection; I’m assuming this will remain in place despite the 
separate discussion on removing the need for officer attestations, and removed 
via a future policy proposal if that action is taken. Please advise if that 
assumption is incorrect.

Thanks,

-C

> On Aug 26, 2021, at 6:54 AM, Rob Seastrom  wrote:
> 
> 
> Dear ARIN Community,
> 
> Please read the updated text for policy proposal ARIN 2020-6 Swap Policy 
> (below) and offer your thoughts and comments.
> 
> All the best,
> 
> -r
> 
> -=-=-=-=-
> 
> ARIN 2020-6 Swap Policy
> 
> Current text:
> 
> 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.
> 
> 
> Add:
> 
> 8.5.5.1- Transfer for the Purpose of Renumbering 
> Organizations with larger direct allocations or assignments than they require 
> may receive transfer of a smaller block for the purpose of renumbering onto 
> the smaller block if they transfer the entire larger block to a qualified 
> recipient under section 8 within one year of receipt of transfer of the 
> smaller block. If the larger block is not transferred within one year of 
> receipt of the smaller block, the smaller block will be ineligible for 
> transfer under sections 8.3 and 8.4, and the organization will be ineligible 
> to receive any further transfers under this policy. 
> 
>   8.5.5.1.1 Smaller Block Size
>   Organizations may qualify to receive transfer of a smaller block by 
> providing documentation to ARIN which details the use of at least 50% of the 
> smaller block size within 24 months. Current use of the larger block may be 
> used to satisfy this criteria. An officer of the organization shall attest to 
> the documentation provided to ARIN
> 
> Current text:
> 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.
> 
> Add:
> 
> 8.5.6.1 Transfer for the Purpose of Renumbering 
> Organizations receiving transfer of a smaller block under section 8.5.5.1 may 
> deduct the larger block they are transferring to a qualified recipient when 
> calculating their efficient utilization of previous blocks under section 
> 8.5.6. 
> 
> Current Text:
> Sections 8.3 and 8.4, under “Conditions on Source Of the Transfer”:   
> “The source entity must not have received a transfer, allocation, or 
> assignment of IPv4 number resources from ARIN for the 12 months prior to the 
> approval of a transfer request. This restriction does not include 8.2 
> transfers.
> 
> Add:
> This requirement may be waived by ARIN for transfers made in connection with 
> a renumbering exercise designed to more efficiently utilize number resources 
> under section 8.5.5.1.
> 
> 
> 
> 
> ___
> 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

[Chris Woodfield]

Support. New language is far more efficient and readable.

Thanks,

-C

> On Aug 18, 2021, at 1:59 PM, 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 as the community review 
> period continues. 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 "The source entity must 
> not have received a transfer, allocation, or assignment of IPv4 number 
> resources from ARIN for the 12 months prior to the approval of a transfer 
> request. Number resources received as the result of an 8.2 transfer are out 
> of scope for the purposes of this restriction." with "Excluding section 8.2 
> transfers, the source entity must not have received a transfer, allocation, 
> or assignment of IPv4 number resources from ARIN during the 12 months prior 
> to the approval of a transfer request."
>  
> 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] Draft Policy ARIN-2021-3: Private AS Number and Unique Routing Policy Clarifications

[Chris Woodfield]

Speaking in support, but I’d like to recommend an adjustment in the proposal 
text. I think the phrase “unique routing policy, such as BGP” is technically 
incorrect; BGP is a protocol, not a policy. BGP is how a network *communicates* 
the relevant aspects of its unique routing policy to its peers, but is not the 
policy in and of itself.

As such, where the proposal text says “unique routing policy, such as BGP”, I 
think this should read “unique routing policy, implemented via BGP” - that 
should fix the bug here.

Hope this helps,

-C

> On 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 is below and can be found at:
>  
> https://www.arin.net/participate/policy/drafts/2021_3/
>  
> 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-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.”
>  
> 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”
>  
> 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.”
>  
> 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/Retitled - Draft Policy ARIN-2021-1: ASN Clarifications to Sections 2 and 8

[Chris Woodfield]

Hi,

These changes make sense and I am in support. My one question is - am I correct 
to assume that where the term “number resources” is replaced with “addresses”, 
the intent is to clarify that the clause in question does not apply to ASNs, 
only address space? And if so, does this result in any potential change in 
effective policy that would take this out of the editorial realm? 

Thanks,

-Chris

> On May 20, 2021, at 11:12 AM, ARIN  wrote:
> 
> The following Draft Policy has been revised and retitled:
> * ARIN-2021-1: ASN Clarifications to Sections 2 and 8
>  
> Revised text is below and can be found at:
> https://www.arin.net/participate/policy/drafts/2021_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
> Senior Policy Analyst
> American Registry for Internet Numbers (ARIN)
>  
> Draft Policy ARIN-2021-1: ASN Clarifications to Sections 2 and 8
>  
> Problem Statement:
> The community has raised concerns that the current language in Section 8 is 
> not clear regarding ASN-only transactions. There are also some language and 
> reference inconsistencies which should be addressed while adjusting Section 8 
> and concordant adjustments to Section 2.
> Policy statement:
> Add a definition for ASN in Section 2:
>  
> Section 2.X Autonomous System Number (ASN)
>  
> An Autonomous System Number (ASN) is a unique identifier which represents a 
> collection of network resources operated under a common routing policy 
> administration, known as an autonomous system.
>  
> In Section 8.2:
>  
> Replace
>  
> “The Internet number resources being transferred as part of an 8.2 transfer 
> will not be subject to a needs-based assessment during the process of the 8.2 
> transfer.”
>  
> with
>  
> “The Internet number resources being transferred as part of a transfer under 
> section 8.2 will not be subject to a needs based assessment during the 
> process of the transfer.”
>  
> Replace
>  
> “The recipient must provide evidence that they have acquired the assets that 
> use the resources to be transferred from the current registrant.”
>  
> with
>  
> “The recipient must provide evidence that it has acquired the assets that use 
> the resources to be transferred from the current registrant.”
>  
> Replace
>  
> “The recipient must show that they have acquired the entire entity which is 
> the current registrant.”
>  
> with
>  
> “The recipient must show that it has acquired the entire entity which is the 
> current registrant.”
>  
> Replace
>  
> “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.”
>  
> with
>  
> “An organization which serves as the source of an IPv4 transfer under section 
> 8.2 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.”
>  
> 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.”
>  
> Replace
>  
> “Number resources received as the result of an 8.2 transfer are out of scope 
> for the purposes of this restriction.”
>  
> with
>  
> “Number resources received as the result of a transfer under section 8.2 are 
> out of scope for the purposes of this restriction.”
>  
> In Section 8.4:
>  
> 

Re: [arin-ppml] Last Call - Recommended Draft Policy ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee

[Chris Woodfield]

I question the use of the word “contractural” vs “contractual” here - per the 
OED, “contractural” has two definitions, one of which is medical, the other 
being “another term for ‘contractual’”*. So while the proposed language is 
technically correct, I feel that I will not be the first or the last person to 
think this might be a typo. I'd recommend changing that word, but otherwise 
support as written.

Thanks,

-Chris

* See https://www.google.com/search?q=contractural - Google's definition 
results are provided by Oxford Languages.

> On Apr 20, 2021, at 11:44 AM, ARIN  wrote:
> 
> On 15 April 2021, the ARIN Advisory Council (AC) sent the following 
> Recommended Draft Policy to Last Call:
>  
> * ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee
>  
> 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_8/ 
> 
>  
> 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-8: Clarify and Update 4.2.1.2 Annual 
> Renewal Fee
>  
> AC Assessment of Conformance with the Principles of Internet Number Resource 
> Policy:
>  
> This Draft Policy is fair, impartial, and technically sound. This draft 
> policy replaces language identified as problematic by ARIN staff via the 
> Policy Experience Report WG with a proper definition to keep the NRPM focused 
> on numbers policy.
>  
> Problem Statement:
>  
> The January 2020 Policy Experience Report highlighted that the existing 
> language in Section 4.2.1.2 “Annual Renewal” references fees. Fees are not 
> considered a member qualification criteria. Since fees aren’t referenced 
> elsewhere in community policy, the wording was reviewed by the PEG.
>  
> Policy Statement:
>  
> Given that the Registration Services Agreement (RSA) already contains 
> language regarding fees, the AC Shepherds recommend to eliminate 4.2.1.2. 
> entirely and add:
>  
> 2.X Registration Services Agreement (RSA)
>  
> Number resources allocated or assigned by ARIN under these policies are 
> subject to a contractural agreement between ARIN and the resource holder. 
> Throughout this document, any and all forms of this agreement, past or 
> future, are simply referred to as the Registration Services Agreement (RSA).
>  
> Comments:
>  
> The AC’s understanding is that community policy should not include language 
> referring to fees, as such language is already present in the Registration 
> Services Agreement (RSA)
>  
> Registration Services has informed us that “Section 4.2.1.2. contains 
> language detailing fee due dates, encouraging on-time payments, and mentions 
> potential revocations. It also contains a reference to web documentation that 
> has evolved significantly since this policy was implemented, and may continue 
> to do so. Essentially the entire section is made of language that is already 
> in the Registration Services Agreement, and is generally fee-focused, making 
> it outside normal scope for Internet number resource policy.”
>  
> Timetable for Implementation: Immediate
>  
> Anything Else: Community input since adopting draft has informed this 
> direction. The 2.X placeholder is used as this seems like it might be 
> foundational enough to not be 2.17 but the Shepherds would rather not upset 
> current indexing arbitrarily.
> ___
> 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] Last Call - Recommended Draft Policy ARIN-2020-7: 4.4 gTLD Micro-allocation Clarification

[Chris Woodfield]

I’d argue that this is not editorial, in that the use of the term “new” at the 
time was intended to exclude the existing gTLDs from eligibility, where the 
proposed language does not. That said, I support as written.

Thanks,

-C

> On Apr 20, 2021, at 11:49 AM, Scott Leibrand  wrote:
> 
> IMO this is editorial, but either way I support the clarification. 
> 
> -Scott
> 
> 
> 
> 
> --
> On Tue, Apr 20, 2021 at 11:43 AM, ARIN mailto:i...@arin.net>> 
> 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.

___
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-2: Special Use IPv4 Space Out of Scope for Purposes of Determining Waitlist Eligibility

[Chris Woodfield]

Given that the impetus for implementing the /20 limit on waitlist eligibility 
was primarily to prevent fraudulent and/or speculative monetization of space 
allocated from the waitlist, I see no reason to oppose this carve-ou, given 
that 4.4 and 4.10 space is ineligible for transfer under Section 8.3. As such, 
I see no loosening of loopholes by adopting this policy.

As a side note, I’d be interested in knowing which allocations have been made 
under these policies, particularly 4.4; given the availability of 
otherwise-unavailable IPv4 space under these policies, the community should 
have an interest in being able to independently verify that resources allocated 
via these policies are, in fact, being used for the purposes stated, which 
should be reasonably simple for an interested community member to determine. Is 
there a method by which these allocations are noted in WHOIS? 

Section 4.10 appears to call for a contiguous /10 to be set aside for its 
purpose, but the actual network number that was reserved does not seem to be 
noted or otherwise easily determined. Can this be published?

Thanks,

-Chris

> On Mar 23, 2021, at 7:59 AM, ARIN  wrote:
> 
> On 18 March 2021, the ARIN Advisory Council (AC) accepted "ARIN-prop-297: 
> Special Use IPv4 Space Out of Scope for Purposes of Determining Waitlist 
> Eligibility" as a Draft Policy.
>  
> Draft Policy ARIN-2021-2 is below and can be found at:
>  
> https://www.arin.net/participate/policy/drafts/2021_2/ 
> 
>  
> 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-2: Special Use IPv4 Space Out of Scope for Purposes of 
> Determining Waitlist Eligibility
>  
> Problem Statement: 
>  
> Eligibility for number resources is based on demonstrated need. In NRPM 
> Section 4, IPv4 demonstrated need is furcated into three categories: ordinary 
> use addresses for ISPs and end users (sections 4.2 and 4.3), special use 
> addresses for critical infrastructure (section 4.4). and special use 
> addresses for facilitation of IPv6 deployment (section 4.10).
>  
> Documentation of need for each category of addresses has always been 
> evaluated without respect for address holdings and utilization of other 
> address categories. For instance a TLD operator could get more section 4.4 
> space for new TLD customers by showing an MOU with ICANN without having to 
> speak to efficient use of its back office section 4.3 space. Likewise, an 
> organization that operated multiple internet exchanges each with a 
> comparatively small number of participants could show efficient use of its 
> section 4.3 back office space and get more under the standard demonstrated 
> need policy despite the fact that its internet exchanges were nowhere near 
> full, thus driving their host density ratio sufficiently low across all their 
> holdings that if they were taken in aggregate they could not possibly meet 
> the requirements to justify more space. Furthermore, an organization that 
> needed address space for IPv6 transition under section 4.10 had those 
> requirements evaluated irrespective of its current holdings and/or efficient 
> utilization.
>  
> The current wording of section 4.1.8 (ARIN Waitlist) begins “ARIN will only 
> issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from 
> the ARIN Waitlist.”, a nod to the fact that there is space held in reserve 
> for this type of special use. However a couple of sentences later, 
> “Organizations which hold more than a /20 equivalent of IPv4 space in 
> aggregate are not eligible to apply.” suggests that special use space might 
> count against an organization wishing to apply for waitlist space despite the 
> fact that based on the terms of its issuance 4.4 and 4.10 space is not to be 
> used for general purposes. Either of the types of organizations described 
> above could easily fall into the corner case of having enough special use 
> space to preclude getting ordinary use space via the waitlist.
>  
> In the Staff and Legal Assessment (1 May 2019) for ARIN-2019-20, Staff noted:
>  
> “… ARIN staff would immediately perform an audit of the current waitlist 

Re: [arin-ppml] Editorial Change ARIN-edit-2020-9: Editorial Clean-up of NRPM Section 4 and Related Provisions

[Chris Woodfield]

Agreed - the linked PDF does not show any redlined changes. Was the wrong 
version of the PDF posted?

-C

> On Mar 23, 2021, at 8:17 AM, Martin Hannigan  wrote:
> 
> 
> 
> Did you mean to say that there was a markup "red line" showing the changes? 
> If there is, I don't see it or anything that lets someone easily ascertain 
> what's being proposed change wise. 
> 
> 
> 
> On Tue, Mar 23, 2021 at 11:11 AM ARIN mailto:i...@arin.net>> 
> wrote:
> On 18 March 2021, the ARIN Advisory Council (AC) classified "ARIN-2020-9: 
> Editorial Clean-up of NRPM Section 4 and Related Provisions" as an Editorial 
> Change to the Number Resource Policy Manual (NRPM).
> 
>  
> 
> The 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. The review period will 
> close on 22 April 2021.
> 
>  
> 
> The Number Resource Policy Manual is available at:
> 
> https://www.arin.net/participate/policy/nrpm/ 
> 
>  
> 
> The PDP is available at:
> 
> https://www.arin.net/participate/policy/pdp/ 
> 
>  
> 
> Regards,
> 
>  
> 
> Sean Hopkins
> 
> Senior Policy Analyst
> 
> American Registry for Internet Numbers (ARIN)
> 
>  
> 
>  
> 
>  
> 
> Editorial Change ARIN-edit-2020-9: Editorial Clean-up of NRPM Section 4 and 
> Related Provisions
> 
>  
> 
> Problem Statement:
> 
>  
> 
> ARIN staff have identified some areas of potential editorial clean-up of 
> section 4 of the NRPM. Building on those recommendations the ARIN AC NRPM 
> Clean-up Working Group undertook an editorial review of section 4.
> 
>  
> 
> 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. 
> In the course of this work, we discovered the need for certain changes to 
> sections 2, 3, and 6. We included those that are editorial in nature in this 
> proposal.
> 
>  
> 
> Other changes to those three sections will be addressed in subsequent 
> proposals. We are also proposing that the NRPM Table of Contents be updated 
> to reflect the editorial changes to the NRPM contents contained in this 
> proposal.
> 
>  
> 
> Policy Statement:
> 
>  
> 
> The changes proposed to be made in this editorial proposal are too numerous 
> to list individually. Accordingly, a document is provided at 
> http://www.arin.net/participate/policy/drafts/pdf/arin_edit_2020_9_v2.pdf 
>   
> that shows the changes being proposed as mark-up text relative to the version 
> of the NRPM in effect when the editorial work of the Working Group started.
> 
>  
> 
> Timetable for Implementation: Immediate
> 
>  
> 
> Anything Else:
> 
>  
> 
> This proposal is intended to be editorial in nature.
> 
> ___
> 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 ARIN-2021-1: ASN Clarifications to Sections 2, 8 and 10

[Chris Woodfield]

Reading these changes, the majority of these proposed updates appear strictly 
editorial, but a few appear to at least have the potential to have an effect on 
policy, however subtle, as references to ASNs are being added in a few places 
where it wasn’t before, replacing the term “IPv4 address resources” had been 
used prior - a term could be interpreted as to *not* include ASNs. 

That said, these changes appear to be a positive clarification of the existing 
policy, and as such, I support as written.

Thanks,

-Chris

> On Mar 9, 2021, at 12:45 PM, ARIN  wrote:
> 
> On 18 February 2021, the ARIN Advisory Council (AC) accepted "ARIN-prop-296: 
> ASN Clarifications to Sections 2, 8 and 10" as a Draft Policy.
>  
> Draft Policy ARIN-2021-1 is below and can be found at:
>  
> https://www.arin.net/participate/policy/drafts/2021_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
> Senior Policy Analyst
> American Registry for Internet Numbers (ARIN)
>  
>  
>  
> Draft Policy ARIN-2021-1: ASN Clarifications to Sections 2, 8 and 10
>  
> Problem Statement: 
>  
> The community has raised concerns that the current language in Section 8 is 
> not clear regarding ASN-only transactions. There are also some language and 
> reference inconsistancies which should be addressed while adjusting Section 8 
> and concordant adjustments to Sections 2 and 10.
>  
> Policy Statement: 
>  
> Add a definition for ASN in Section 2:
>  
> Section 2.X Autonomous System Number (ASN)
>  
> An Autonomous System Number (ASN) is a unique identifier which represents a 
> collection of network resources operated under a common routing policy 
> administration, known as an autonomous system.
>  
> In Section 8.2:
>  
> Replace
>  
> “The Internet number resources being transferred as part of an 8.2 transfer 
> will not be subject to a needs-based assessment during the process of the 8.2 
> transfer.”
>  
> with
>  
> “The Internet number resources being transferred as part of a transfer under 
> section 8.2 will not be subject to a needs-based assessment during the 
> process of the transfer.”
>  
> Replace
>  
> “The recipient must provide evidence that they have acquired the assets that 
> use the resources to be transferred from the current registrant.”
>  
> with
>  
> “The recipient must provide evidence that it has acquired the assets that use 
> the resources to be transferred from the current registrant.”
>  
> Replace
>  
> “The recipient must show that they have acquired the entire entity which is 
> the current registrant.”
>  
> with
>  
> “The recipient must show that it has acquired the entire entity which is the 
> current registrant.”
>  
> Replace
>  
> “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.”
>  
> with
>  
> “An organization which serves as the source of an IPv4 transfer under section 
> 8.2 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.”
>  
> 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.”
>  
> Replace
>  
> “Number resources received as the result of an 8.2 transfer are out of 

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

[Chris Woodfield]

Obviously this thread is going somewhat off-topic and my reply isn’t going to 
help matters - the idea that peer to peer is useless is a factor, but it’s more 
than that - it’s the fact that the vast majority of customers, service 
providers, and operators have come to view NAT and the use of private space as 
a form of security perimeter, and that allowing internal hosts/networks to be 
numbered from globally-routable space represents a security risk.

You, I, and most of the people reading PPML know that mindset is completely 
fallacious, but it’s quite pervasive and takes quite a bit of education to 
disabuse otherwise quite savvy operators of this notion.

It’s interesting that a lot of IPv6 evangelism that I’ve seen over the years 
doesn’t address this concern - IMO we should be spending quite a bit of energy 
fighting that mindset.

-C

> On Jan 15, 2021, at 11:39 PM, Owen DeLong  wrote:
> 
> The biggest problem surrounding IPv4 is this idea that peer to peer is 
> useless and we should all accept the idea of provider/supplicant and second 
> class citizens.
> 

___
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-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee

[Chris Woodfield]

The language, as is, is problematic because there’s a clear delineation between 
the NRPM and ARIN’s RSA/LRSAs. The former is intended to focus solely on 
allocation policies, and is a living document subject to change via the PDP. 
The RSA/LRSA agreements, however, are contracts whose language can only be 
modified by action from ARIN’s Board of Trustees. Contractual language on 
member fees, terms and conditions, and related topics are solely the domain of 
the RSA, and as such the inclusion of language regarding fees in the NRPM 
should be stricken - this language is already present in the RSA, where it 
belongs.

The primary reason for this delineation, as I understand it is that language in 
the RSA is necessary contractual language that ARIN must have in order to 
provide the necessary income to fulfill ARIN’s mission and responsibilities, 
and to protect ARIN from unnecessary legal liabilities that may threaten that 
mission. While number policy is subject to a community-driven policy 
development process, the language in ARIN's RSAs, for what I hope are obvious 
reasons, must be controlled far more tightly, hence the separation between the 
two.

I hope this helps clarify things.

-Chris

> On Jan 15, 2021, at 3:36 PM, Fernando Frediani  wrote:
> 
> Applies to all resources of course. If not in the appropriate place then add 
> it there then. But not remove something that is very obvious.
> 
> How can it deal with the issues better by removing from the text that part 
> that makes it clear that resources may be revoked if they are not payed ?
> 
> Fernando
> 
> On 15/01/2021 20:33, David Farmer wrote:
>> Are you saying fees only apply to ISPs with IPv4, the current text is in 
>> section 4.2.1.4, where section 4.2 applies to Allocations to ISPs...
>> 
>> Furthermore, not paying fees is only one reason resources may be revoked or 
>> reclaimed.
>> 
>> I think the new text is a better way to deal with the issues.
>> 
>> On Fri, Jan 15, 2021 at 17:09 Fernando Frediani > > wrote:
>> Yes fees are most a RSA thing, but I see no harm to keep the actual wording 
>> as it is and make it loud and clear that organizations that don't pay the 
>> fees are subjected to resources revocation - which is up to this forum to 
>> define - so no one may plead ignorance about it. 
>> What is the problem to keep it as it is ? If the newly proposed text 
>> mentions that ISPs should take care to ensure that their annual renewal 
>> payment is made by their anniversary due date, what's wrong to also remind 
>> them that if that is not fulfilled the resources may be revoked ?
>> This makes part of the Fair and Impartial Number Resources Administration 
>> principle.
>> 
>> I see no propose in this proposal therefore I do not support it.
>> 
>> Regards
>> Fernando
>> 
>> On 15/01/2021 17:55, ARIN wrote:
>>> The following Draft Policy has been revised:
>>> 
>>>  
>>> * ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee
>>> 
>>>  
>>> Revised text is below and can be found at:
>>> 
>>>  
>>> https://www.arin.net/participate/policy/drafts/2020_8/ 
>>> 
>>>  
>>> 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-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee
>>> 
>>>  
>>> Problem Statement:
>>> 
>>>  
>>> The January 2020 Policy Experience Report highlighted that the existing 
>>> language in Section 4.2.1.2 "Annual Renewal" references fees. Fees are not 
>>> considered a member qualification criteria. Since fees aren't referenced 
>>> elsewhere in community policy, the wording was reviewed by the PEG.
>>> 
>>>  
>>> Policy statement:
>>> 
>>>  
>>> Given that the Registration Services Agreement (RSA) already contains 
>>> language regarding fees, the AC Shepherds recommend to eliminate 4.2.1.2. 
>>> entirely and add:
>>> 
>>>  
>>> 2.X Registration Services Agreement (RSA)
>>> 
>>>  
>>> Number resources allocated or assigned by ARIN under these policies are 
>>> subject to a contractural agreement between ARIN and the resource holder. 

Re: [arin-ppml] Open Petition for ARIN-2020-2

[Chris Woodfield]

Thank you for the explanation. One follow-up question I’d ask about this 
process - if the petition succeeds and the proposal is put before the Board for 
consideration, is it expected that the Board will consider the policy with, or 
explicitly without, taking into account the route it took to come before the 
board? While it’s clear that all Board members would be aware of this, would 
they be encouraged to keep it in mind, or to explicitly put it aside, as part 
of each member’s individual decision-making criteria? (and if not, should they 
be?)

Thanks,

-C

> On Jan 14, 2021, at 9:03 AM, Paul Andersen - ARIN  wrote:
> 
> Michael,
> 
> It may be useful to delineate the two elements of the process in the PDP and 
> how they will be conducted.
> 
> The current stage is that staff are counting the number of individuals that 
> voice support for the policy in question to be moved to the Board of Trustees 
> for consideration. The PDP has always kept low thresholds for petition 
> processes as a petition doesn’t automatically adopt a policy but simply 
> advances it further in the process.  At this point, staff are only evaluating 
> the criteria that there be 25 individuals in the time period indicated and 
> that those individuals not be from the same organization to determine if the 
> petition is successful.
> 
> If the threshold is met the policy will be put before the Board of Trustees 
> for consideration. The Board does not “count” the votes when weighing 
> community support or the policy. The Board instead will need to weigh quite a 
> bit of data against the Principles of Internet Number Resource Policy stated 
> in the PDP and this includes community support. The Board will ultimately 
> come to its own view as to whether the policy change meets the criteria, as a 
> successful petition simply brings it before them for consideration.
> 
> The Board (and staff) are observing this process and comments on the list 
> will be considered. The community (including the AC) should feel free to, and 
> are fact highly encouraged to, engage in meaningful discussion of the merits 
> of the policy. If members of the community have questions for other community 
> members they are free to ask those. The only reminder is any such discussion 
> MUST follow the ARIN Mailing List Appropriate Usage Policy.
> 
> The Board appreciates all those who engage in this process and strongly 
> encourages everyone in the community to engage here. Our decision process is 
> always enhanced by plentiful community input.
> 
> Cheers,
> 
> Paul
> 
> —
> Paul Andersen, P. Eng
> Chair, ARIN Board of Trustees
> p...@arin.net 
> 
>> On Jan 14, 2021, at 11:00 AM, Michael B. Williams 
>>  wrote:
>> 
>> Question for ARIN Employees/ others on PPLM -
>> 
>> How does ARIN analyze the response from this? Is there weight given only to 
>> ARIN member organizations or any organization? If anyone is given 
>> consideration, what is to stop people from lobbying individuals and other 
>> organizations to send an email to support their agenda? For example, I could 
>> very easily find 500 people to respond to this email saying they do not 
>> support the policy. If I were a malicious actor trying to influence policy 
>> discussion and were to offer some sort of incentive for those to reply I 
>> could easily have thousands of organizations supporting this policy one way 
>> or another. 
>> 
>> My feelings would be the majority of the weight should be given to ARIN 
>> member organizations voices as part of the tallying process. If that is the 
>> case, perhaps we should ask those organizations to include their ARIN org id?
>> 
>> Michael B. Williams 
>> Glexia, Inc. - An IT Company
>> USA Direct: +1 978 477 6797
>> USA Toll Free: +1 800 675 0297 x101
>> AUS Direct: +61 3 8594 2265
>> AUS Toll Free: +61 1800 931 724 x101
>> Fax: +1.815-301-5570
>> michael.willi...@glexia.com 
>> https://www.glexia.com/ 
>> https://www.glexia.com.au/ 
>> 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, Jan 11, 2021 at 9:17 AM ARIN mailto:i...@arin.net>> 
>> wrote:
>> A petition has been initiated for the following:
>> 
>>  
>> 
>> ARIN-2020-2: Reinstatement of Organizations Removed from Waitlist by 
>> Implementation of ARIN-2019-16
>> 
>>  
>> 
>> ARIN-2020-2 reverted to Draft Policy on 6 January following a Last Call 
>> period. Per ARIN's Policy Development Process (PDP), all Recommended Draft 
>> Policies not sent to the ARIN 

Re: [arin-ppml] Board of Trustees Consideration Petition for ARIN -2020 -2: Reinstatement of Organizations Removed from Waitlist by Implementation of ARIN-2019-16

[Chris Woodfield]

FD: I am a former ARIN AC Member, and was a member of the AC at the time of the 
December meeting. That said, I am speaking as a community member below in a 
personal capacity.

I’ll admit that as this proposal wended it way through the PDP, my opinion on 
whether or not to support it has changed more than once. The record shows that 
I voted to advance the proposal to the Board for during the November meeting, 
but voted against the same motion in December. Take that whatever way you 
choose, but I can say that my change of mind on this last year did not happen 
in a vacuum.

I’d like to address the following statement in your petition: "when given the 
opportunity to explain their rationale behind their vote against, 4 of the 6 AC 
council members have not responded.” 

The Advisory Council, like all deliberative bodies, often engages in robust 
debates, which are captured in as much detail as possible in the published 
minutes, and engages with the community as extensively as is appropriate. But 
the assertion that AC members are expected to individually explain their 
decisions to the community, or to individual members thereof, on demand is an 
assertion I find grossly unreasonable and, frankly, rather offensive, and the 
implication that the lack of such explanation-on-demand is a dereliction of AC 
members’ duties even more so.

Mr. Farmer, also a AC alumnus, wisely implores us to disregard any accusations 
or implications of nefarious motivations for supporting this policy. That said, 
generally speaking, I do not believe that it is out of order to make judgement 
calls on the tactics that the proponents for or against any given action employ 
to lobby their cause, and it’s not out of line to question the motivations 
behind that advocacy when those tactics seem grossly disproportionate to the 
matter at hand.

As such, speaking as a community member, I continue to oppose this policy, and 
am stating my explicit lack of support for this petition.

Thanks,

-C


> On Jan 10, 2021, at 8:08 AM, Tom Pruitt  wrote:
> 
>Stratus Networks is officially petitioning the Board of 
> Trustees on policy ARIN -2020 -2: Reinstatement of Organizations Removed from 
> Waitlist by Implementation of ARIN-2019-16 against reversion back to draft 
> status and moving to have it  sent directly to the Board of Trustees for 
> immediate approval.
>  
>We are requesting that all in favor of this proposal voice 
> their approval on the PPML.
>  
> Per section 2.4 of the PDP:
>  
> 2.4. Petition for Board of Trustees Consideration
> Any member of the community may initiate a Board of Trustees Consideration 
> Petition if they are dissatisfied with the Advisory Council’s failure to act 
> within the allotted time (60 days) to send a Recommended Draft Policy in last 
> call to the Board of Trustees for consideration. A successful petition for 
> Board of Trustees Consideration requires expressions of petition support from 
> at least 25 different people from 25 different organizations. If successful, 
> this petition will send the Recommended Draft Policy from last call to the 
> Board of Trustees for consideration.
>  
>  
> In our opinion, this proposal clearly met the criteria necessary 
> for adoption by ARIN.  Our reasoning is outlined below. 
> 
>  
> In order to get new policy, as drawn directly from the PDP:
>  
> Principles of Internet Number Resource Policy
>  
> Internet number resource policy must satisfy three important principles, 
> specifically: 1) enabling fair and impartial number resource administration, 
> 2) technically sound (providing for uniqueness and usability of number 
> resources), and 3) supported by the community.
>  
>  
>   • Enabling fair and impartial number resource administration:
> 
> In the discussion about fairness, much of the dissenting 
> discussion related to how this would negatively affect the current 
> organizations on the list.  While that question has been answered, that it 
> will have no effect, it is a great and valid question that should be asked 
> and answered. It is the entire point of this proposal.  The same question 
> should have been addressed when the waitlist was changed. How can one 
> rationalize that this would be unfair to the current people on the list, but 
> not use the same rationale on the people that were on the original waitlist?  
>  If one does not believe grandfathering is fair, how can they ever support a 
> proposal that has grandfathering in it without contradicting themselves?  
>  
> For the record, AC council member Joe Provo waited until the 
> meeting after last call to quote the definition of fairness to the council.  
> We believe that he mis-quoted that definition.  To the extent that anyone 
> relied on his definition, we would like to set the record straight. 
>  
>  
> As taken directly from the minutes:
> “All 

Re: [arin-ppml] Revised - Draft Policy ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee

[Chris Woodfield]

FD: This policy is a work produce of the AC’s Policy Experience Report working 
group, which I currently chair.

Taking my AC/WG chair hat off, I am in support of the updated language, with 
the caveat that the following assumptions can be relied upon:

1. The added language cannot be interpreted to place additional conditions on 
legacy resource holders that do not exist today. I’m interpreting the reference 
to resources “allocated and assigned under these policies” as implicitly 
excluding legacy resource holders, but please correct me if that assumption is 
incorrect.

2. The term “Registration Services Agreement” is used generically, and is 
inclusive of RSA and LRSA agreements, or other future agreements ARIN may have 
with resource holders.

Thanks,

-C

> On Nov 20, 2020, at 9:55 AM, ARIN  wrote:
> 
> The following Draft Policy has been revised:
>  
> * ARIN-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee
>  
> Revised text is below and can be found at:
>  
> https://www.arin.net/participate/policy/drafts/2020_8/ 
> 
>  
> 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-2020-8: Clarify and Update 4.2.1.2 Annual Renewal Fee
>  
> Problem Statement:
>  
> The January 2020 Policy Experience Report highlighted that the existing 
> language in Section 4.2.1.2 "Annual Renewal" references fees. Fees are not 
> considered a member qualification criteria. Since fees aren't referenced 
> elsewhere in community policy, the wording was reviewed by the PEG.
>  
> Policy Statement:
>  
> Given that the Registration Services Agreement (RSA) already contains 
> language regarding fees, the AC Shepherds recommend to eliminate 4.2.1.2. 
> entirely and add:
>  
> 2.X Registration Services Agreement (RSA)
>  
> Number resources allocated or assigned by ARIN under these policies are 
> subject to a Registration Services Agreement (RSA) between ARIN and the 
> resource holder. This agreement covers terms, rights, responsibilities and 
> conditions of service; failure to adhere to the RSA may result in revocation 
> of number resources.
>  
> Comments:
>  
> The AC’s understanding is that community policy should not include language 
> referring to fees, as such language is already present in the Registration 
> Services Agreement (RSA)
>  
> Registration Services has informed us that "Section 4.2.1.2. contains 
> language detailing fee due dates, encouraging on-time payments, and mentions 
> potential revocations. It also contains a reference to web documentation that 
> has evolved significantly since this policy was implemented, and may continue 
> to do so. Essentially the entire section is made of language that is already 
> in the Registration Services Agreement, and is generally fee-focused, making 
> it outside normal scope for Internet number resource policy."
>  
> Timetable for Implementation: Immediate
>  
> Anything Else: Community input since adopting draft has informed this 
> direction. The 2.X placeholder is used as this seems like it might be 
> foundational enough to not be 2.17 but the Shepherds would rather not upset 
> current indexing arbitrarily.
> ___
> 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 2020-3

[Chris Woodfield]

Scott - can confirm from my own experience you are correct. An end-user that 
signs to the RSP is considered an ISP from both a fee and policy perspective, 
and as John stated, is a one-way conversion. As mentioned previously, the 
ability to utilize SWIP to reassign blocks need not be in an ISP-to-customer 
context; there are a number of reasons an organization may wish to publish SWIP 
data for blocks assigned internally. 

Hope this clarifies things :)

-C

> On Oct 12, 2020, at 4:44 PM, sc...@solarnetone.org wrote:
> 
> Thanks for the clarification, John.
> 
> On Mon, 12 Oct 2020, John Sweeting wrote:
> 
>> 
>> 
>> On 10/12/20, 7:09 PM, "ARIN-PPML on behalf of Andrew Dul" 
>>  wrote:
>> 
>>   On 10/12/2020 3:40 PM, sc...@solarnetone.org wrote:
>>   > Hi Andrew,
>>   >
>>   >>>
>>   >>> Unfortunately, the only way to have redundancy in your upstream while
>>   >>> keeping connectivity to your network address is to be an ISP by this
>>   >>> definition, even if you offer no network services to other
>>   >>> organizations.
>>   >>> This is because an AS is required to perform BGP, which is critical to
>>   >>> maintaining connectivity to a multi-homed network through outage of
>>   >>> one or more connected circuits.
>>   >>
>>   >>
>>   >> ARIN's definition of ISP/end-user is related to the services ARIN offers
>>   >> to an organization and may not be specifically tied to a "classic"
>>   >> definition of an ISP.
>>   >
>>   > Precisely what I was trying, if failing, to express.  David's post
>>   > clarified the delineation.  I see from the NRPM that there is a minor
>>   > difference in fee schedule too.  For example, an end user with a /44
>>   > or /48 of v6, a /24 of v4, and an ASN would pay approximately
>>   > $200/year more than a 3x-small, and $50 less than a 2x-small.
>>   >
>>   > This applies, however, only to those who do not subscribe to the
>>   > Registration Services Plan, if I understand correctly, as subscribing
>>   > to said plan converts one from End User to ISP automatically.
>>   > Needless to say, there are organizations that are end users by
>>   > functional definition here, but subscribe to the service plan, and/or
>>   > choose to be an ISP for other reasons.
>> 
>>   My understanding is that subscribing to 'Registration Services Plan'
>>   does not change you from an end-user to ISP, it just gives you access to
>>   the services available under that plan and the resulting fee schedule.
>>   You can presumably decide to go back to classic 'pay by the resource
>>   option' as an end-user if you didn't need the extra services or
>>   preferred the alternate fee calculation.
>> 
>> (JS) Converting to an Registration Services Plan is a one time, one way 
>> action. There is no converting back to EU 'pay by the resource option' once 
>> an organization has completed actions necessary to convert to Registration 
>> Services Plan.
>> 
>> 
>>   >
>>   >>
>>   >>
>>   >>>
>>   >>>>
>>   >>>> An end-user organization who would be eligible to obtain an /48 under
>>   >>>> 6.5.8 of the NRPM.
>>   >>>>
>>   >>>> 
>> https://www.arin.net/participate/policy/nrpm/#6-5-8-direct-assignments-from-arin-to-end-user-organizations
>>   >>>>
>>   >>>>
>>   >
>>   > True, but I was referring to protocol version agnostic multi-homing.
>>   > Would an end user also qualify for 4.10 v4 space by requesting a /44
>>   > or /48 directly from ARIN?
>>   >
>>   I believe the answer is yes, 4.10, is agnostic to your ISP/End-user
>>   status w/ ARIN.
>> 
>>   >>>>
>>   >>>> This draft policy ARIN-2020-3 is specifically related to ISPs.
>>   >>>
>>   >>> I believe you are making a misclassification here.  Once these
>>   >>> organizations have AS and/or address resources, they are considered an
>>   >>> ISP for these purposes, despite their end use case.
>>   >>
>>   >> I disagree, others feel free to correct me.
>>   >
>>   > You are right.  Pardon my confusion.
>>   >
>>   > Scott
>>   >
>>   >
>>   >>
>>   >>
>>   >>
>>   >>>>
>>   >>>>
>>   &

Re: [arin-ppml] Draft Policy ARIN 2020-3

[Chris Woodfield]

Agreed. To be clear, I did not intend for my question to imply that the goal of 
keeping the proposal revenue-neutral was in any way dishonorable - ARIN’s 
financial stability is obviously in the community’s best interests. But we 
should have informed consent as to how that stability is achieved, and as such, 
clarifying the intention of the clause is helpful.

Thanks,

-C

> On Oct 12, 2020, at 11:06 AM, sc...@solarnetone.org wrote:
> 
> Hi Chris,
> 
> Indeed.  To be fair, I think the price is fair for value received, speaking 
> as a 2x-small ISP with a /36.  I was able to lower my recurring costs and 
> increase my available address pool by bringing up an AS at the 2x-small rate. 
>  Allowing the smallest ISPs to implement IPv6 without additional financial 
> cost seems a prudent way to overcome barriers to adoption.
> 
> Scott
> 
> On Sun, 11 Oct 2020, Chris Woodfield wrote:
> 
>> Thanks Andrew, and good catch - both Scott and I missed that clause, 
>> obviously. It appears that this is in place in order to meet the stated goal 
>> of this proposal being revenue-neutral for ARIN? If so, it would be great to 
>> clarify so that community members can make a more informed evaluation as to 
>> whether or not to support the clause. If there are other justifications for 
>> the clause’s presence, I’d be interested to hear them.
> 2~>
>> Thanks,
>> 
>> -C
>> 
>>> On Oct 11, 2020, at 10:24 AM, Andrew Dul  wrote:
>>> 
>>> The current draft policy text disallows returns to lower than a /36, so
>>> I would say that organization which took a /36 would not be permitted to
>>> go down to a /40.
>>> 
>>> "Partial returns of any IPv6 allocation that results in less than a /36
>>> of holding are not permitted regardless of the ISP’s current or former
>>> IPv4 number resource holdings."
>>> 
>>> Andrew
>>> 
>>> On 10/9/2020 2:04 PM, Chris Woodfield wrote:
>>>> Hi Scott,
>>>> 
>>>> Given that ARIN utilizes a sparse allocation strategy for IPv6 resources 
>>>> (in my organization’s case, we could go from a /32 to a /25 without 
>>>> renumbering), IMO it would not be unreasonable for the allocation to be 
>>>> adjusted down simply by changing the mask and keeping the /36 or /32 
>>>> unallocated until the sparse allocations are exhausted. Any resources 
>>>> numbered outside the new /40 would need to be renumbered, to be sure, but 
>>>> that’s most likely less work than a complete renumbering.
>>>> 
>>>> That said, I’ll leave it up to Registration Services to provide a 
>>>> definitive answer.
>>>> 
>>>> -C
>>>> 
>>>>> On Fri, 9 Oct 2020, sc...@solarnetone.org wrote:
>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> I am in favor of this draft, and am curious as to how resource holders 
>>>>>> who were not dissuaded by the fee increase will be impacted by the 
>>>>>> policy change. While they indeed have more address space than /40, they 
>>>>>> may also not need the additional address space.  Some might prefer the 
>>>>>> nano-allocation given the lower cost.  Will they be required to change 
>>>>>> allocations, and renumber, in order to return to 3x-small status and 
>>>>>> associated rate?
>>>>>> 
>>>>>> Scott Johnson
>>>>>> SolarNetOne, Inc.
>>>>>> AS32639
>>>>>> ___
>>>>>> 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] Inter-RIR transfer Policy reciprocity with Afrinic_Resource Transfer Policy proposal

[Chris Woodfield]

Milton - I don’t think ARIN is being inhospitable. I’d argue that as the NRPM 
is currently written, the determination on whether or not AFRINIC’s Inter-RIR 
transfer policy meets the conditions set out in ARIN NRPM 8.4 *as written* is 
not a determination to be made by ARIN staff, not via community consensus. 

What is germane to the ARIN community here is that if the determination is that 
the AFRINIC policy is not compatible, but the community disagrees with that 
determination, then the PDP is available to the community to craft new policy 
with the goal of resolving whatever incompatibility exists.

A rough analogy would be that ARIN staff is the judiciary, and the ARIN 
community is the legislature. If a legislature disagrees with a judicial 
decision interpreting a law as written, the legislature can change the law.

Thanks,

-C

> On Oct 12, 2020, at 10:15 AM, Mueller, Milton L  wrote:
> 
> John I do not understand why ARIN is being so inhospitable in this case.
> Obviously there is uncertainty and misunderstandings could be avoided if the 
> discussion takes place in the open. Staff determinations also need to be 
> accountable to the ARIN members and community. 
> --MM
>  
> From: ARIN-PPML  On Behalf Of John Curran
> Sent: Monday, October 12, 2020 10:43 AM
> To: Anthony Ubah 
> Cc: Eddy Kayihura ; Taiwo Oyewande 
> ; arin-ppml@arin.net
> Subject: Re: [arin-ppml] Inter-RIR transfer Policy reciprocity with 
> Afrinic_Resource Transfer Policy proposal
>  
> On 12 Oct 2020, at 8:30 AM, Anthony Ubah  > wrote:
> For the sake of better understanding, please let me clarify a few things:
>  
> One, it would be arduous and complicated if there is a middleman fugure 
> mediating the conversation between ARIN, AFRINIC, and us the proposal 
> authors. I would love to explore an option of communicating directly. We are 
> also looking forward to the discussion from the ARIN community. 
>  
> Lastly, the version sent by the Afrinic staff to the RPD list is not the 
> latest text draft(shared in this thread), an thus we wish to discuss the 
> newest version with the ARIN community directly.
>  
> Anthony -  
>  
> You indicate that you wish to discuss the proposal with the ARIN community, 
> but you also note that you seek to “inquire about its reciprocity with ARIN” 
> – which is a determination that must be made by ARIN staff. 
>  
> This is likely the source of confusion, since if the topic you’d like to 
> discuss with the ARIN community whether the proposal meets ARIN’s NRPM 
> section 8.4 requirement ("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.”), it’s probably more likely a 
> discussion with ARIN staff that you seek regarding the compatibility of the 
> proposal.  However, for sake of expediency, let’s proceed with that 
> discussion here on the ppml list, as it’s possible that doing so may lead to 
> related discussions on ARIN number resource policy. 
>  
> In order to get the discussion moving, I’d like to get clarity on two 
> questions regarding your proposed policy – 
>  
> 1. Does the policy impose any conditions on recipient organizations in the 
> ARIN region receiving transfers from AFRINIC-served entities?
>  
> 2. Does the policy impose any conditions on source organizations in the ARIN 
> region doing transfers to AFRINIC-served entities?
>  
> (These two questions are germane because when ARIN is reviewing InterRIR 
> transfer requests, we simply apply the criteria provided in the NRPM – i.e. 
> we do not evaluate requests against any conditions or criteria that may be 
> contained in other RIR policy documents...) 
>  
> 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 2020-3

[Chris Woodfield]

Thanks Andrew, and good catch - both Scott and I missed that clause, obviously. 
It appears that this is in place in order to meet the stated goal of this 
proposal being revenue-neutral for ARIN? If so, it would be great to clarify so 
that community members can make a more informed evaluation as to whether or not 
to support the clause. If there are other justifications for the clause’s 
presence, I’d be interested to hear them.

Thanks,

-C

> On Oct 11, 2020, at 10:24 AM, Andrew Dul  wrote:
> 
> The current draft policy text disallows returns to lower than a /36, so
> I would say that organization which took a /36 would not be permitted to
> go down to a /40.
> 
> "Partial returns of any IPv6 allocation that results in less than a /36
> of holding are not permitted regardless of the ISP’s current or former
> IPv4 number resource holdings."
> 
> Andrew
> 
> On 10/9/2020 2:04 PM, Chris Woodfield wrote:
>> Hi Scott,
>> 
>> Given that ARIN utilizes a sparse allocation strategy for IPv6 resources (in 
>> my organization’s case, we could go from a /32 to a /25 without 
>> renumbering), IMO it would not be unreasonable for the allocation to be 
>> adjusted down simply by changing the mask and keeping the /36 or /32 
>> unallocated until the sparse allocations are exhausted. Any resources 
>> numbered outside the new /40 would need to be renumbered, to be sure, but 
>> that’s most likely less work than a complete renumbering.
>> 
>> That said, I’ll leave it up to Registration Services to provide a definitive 
>> answer.
>> 
>> -C
>> 
>>> On Fri, 9 Oct 2020, sc...@solarnetone.org wrote:
>>> 
>>>> Hi All,
>>>> 
>>>> I am in favor of this draft, and am curious as to how resource holders who 
>>>> were not dissuaded by the fee increase will be impacted by the policy 
>>>> change. While they indeed have more address space than /40, they may also 
>>>> not need the additional address space.  Some might prefer the 
>>>> nano-allocation given the lower cost.  Will they be required to change 
>>>> allocations, and renumber, in order to return to 3x-small status and 
>>>> associated rate?
>>>> 
>>>> Scott Johnson
>>>> SolarNetOne, Inc.
>>>> AS32639
>>>> ___
>>>> 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] Draft Policy ARIN 2020-3

[Chris Woodfield]

Hi Scott,

Given that ARIN utilizes a sparse allocation strategy for IPv6 resources (in my 
organization’s case, we could go from a /32 to a /25 without renumbering), IMO 
it would not be unreasonable for the allocation to be adjusted down simply by 
changing the mask and keeping the /36 or /32 unallocated until the sparse 
allocations are exhausted. Any resources numbered outside the new /40 would 
need to be renumbered, to be sure, but that’s most likely less work than a 
complete renumbering.

That said, I’ll leave it up to Registration Services to provide a definitive 
answer.

-C

> On Fri, 9 Oct 2020, sc...@solarnetone.org wrote:
> 
>> Hi All,
>> 
>> I am in favor of this draft, and am curious as to how resource holders who 
>> were not dissuaded by the fee increase will be impacted by the policy 
>> change. While they indeed have more address space than /40, they may also 
>> not need the additional address space.  Some might prefer the 
>> nano-allocation given the lower cost.  Will they be required to change 
>> allocations, and renumber, in order to return to 3x-small status and 
>> associated rate?
>> 
>> Scott Johnson
>> SolarNetOne, Inc.
>> AS32639
>> ___
>> 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 ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers

[Chris Woodfield]

> On Jul 16, 2020, at 11:06 AM, John Santos  wrote:
> 
> On 7/16/2020 11:39 AM, Kat Hunter wrote:
> [...]
>> 4.2.3.6 Original Text:
>> Under normal circumstances an ISP is required to determine the prefix size 
>> of their reassignment to a downstream customer according to the guidelines 
>> set forth in RFC 2050. Specifically, a downstream customer justifies their 
>> reassignment by demonstrating they have an immediate requirement for 25% of 
>> the IP addresses being assigned, and that they have a plan to utilize 50% of 
>> their assignment within one year of its receipt. This policy allows a 
>> downstream customer’s multihoming requirement to serve as justification for 
>> a /24 reassignment from their upstream ISP, regardless of host requirements. 
>> Downstream customers must provide contact information for all of their 
>> upstream providers to the ISP from whom they are requesting a /24. The ISP 
>> will then verify the customer’s multihoming requirement and may assign the 
>> customer a /24, based on this policy. Customers may receive a /24 from only 
>> one of their upstream providers under this policy without providing 
>> additional justification. ISPs may demonstrate they have made an assignment 
>> to a downstream customer under this policy by supplying ARIN with the 
>> information they collected from the customer, as described above, or by 
>> identifying the AS number of the customer. This information may be requested 
>> by ARIN staff when reviewing an ISP’s utilization during their request for 
>> additional IP addresses space.
>> 
> New version of proposed 4.2.3.6 replacement:
> 
>> 4.3.2.6 New Text, replacing old:
>> If a downstream customer has a requirement to multihome, that requirement 
>> alone will serve as justification for a /24 allocation. Downstream customers 
>> must provide contact information for all of their upstream providers to the 
>> ISP from whom they are requesting a /24, and utilize BGP as the routing 
>> protocol between the customer and the ISP. Customers may receive a /24 from 
>> only one of their upstream providers under this policy without providing 
>> additional justification. ISPs may demonstrate they have made an assignment 
>> to a downstream customer under this policy by supplying ARIN with the 
>> information they collected from the customer, as described above, or by 
>> identifying the AS number of the customer.
>> 
>> -Kat Hunter
>> [...]
> Older version of proposed 4.2.3.6:
>> 
>> 4.2.3.6. Reassignments to Multihomed Downstream Customers
>> 
>> If a downstream customer has a requirement to multihome, that 
>> requirement alone will serve as justification for a /24 allocation. 
>> Downstream customers must provide contact information for all of their 
>> upstream providers to the ISP from whom they are requesting a /24, and 
>> utilize BGP as the routing protocol between the customer and the ISP. 
>> Customers may receive a /24 from only one of their upstream providers 
>> under this policy without providing additional justification. ISPs may 
>> demonstrate they have made an assignment to a downstream customer under 
>> this policy by supplying ARIN with the information they collected from 
>> the customer, as described above, or by identifying the AS number of the 
>> customer.
>> 
>> Timetable for implementation: Immediate
> I haven't digested this proposal sufficiently to have an opinion one way or 
> the other, but I do have a general and a specific question.  Doesn't ARIN 
> attempt to avoid mandating particular network technologies in policy, so as 
> not to impede technological advances?
> 
> I am particularly referring to BGP in both versions of the proposed new 
> policy.  Would it be better to develop wording that would suggest BGP until 
> something better comes along, by not specifically refer to it in the policy 
> text?  Or is BGP considered to be as good as it's ever going to get, at least 
> for IPv4 routing?
> 
> 
> 
Speaking as one fo the proposal's authors, I appreciate and agree with that bit 
of feedback. The intent was to express the requirement that the customer route 
the prefix over multiple upstream ISPs; while in practical terms, BGP is the 
only reasonable way to do this, the policy text should not preclude other 
approaches.

Thanks,

-C

> -- 
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
> ___
> 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-2020-2: Grandfathering ofOrganizations Removed from Waitlist by Implementation of ARIN-2019-16

[Chris Woodfield]

Speaking in a personal capacity: I do not support this policy proposal.

I’d been struggling to express my reasoning in a succinct manner, but Hayee’s 
comment helped - organizations who had made business plans that were dependent 
on obtaining IPv4 space through the waiting list process only have themselves 
to blame for not accounting for the possibility of never being able to obtain 
that space. As Andrew has mentioned, an application on the waiting list was 
never intended to be a guarantee of getting space on any timeframe, if ever, 
and organizations that failed to make contingency plans for that possibility 
should not be blaming ARIN for their own planning failures.

Speaking from the perspective of an individual ARIN Advisory Council member (to 
be clear, *not* speaking for the AC as a whole), some very difficult policy 
choices had to be made in response to the waiting list suspension to balance 
the needs of the community with the clear need to 1. prevent future abuse of 
the waiting list to obtain valuable IPv4 resources and 2. ensure a more 
equitable distribution of those resources. We might have not gotten it perfect 
- which is why we have a PDP, and why proposals such as this going through that 
process - but in this case I feel that the AC made the right choice here, and 
to roll that back now would be a disservice to those currently on the waiting 
list.

Thanks,

-Chris

> On Jul 15, 2020, at 6:50 AM, Hayee Bokhari  wrote:
> 
> I fully support this policy, 
> 
> lot of parties suffered from this, months of planning went in the drain.
> 
> Regards
> Hayee Bokhari
> 514-341-1579 Ex 212
> 800-427-6012 Ex 212
> bokh...@cronomagic.com
> http://www.cronomagic.com
> 
>> On 19 March 2020, the ARIN Advisory Council (AC) accepted 
>> "ARIN-prop-282: Grandfathering of Organizations Removed from Waitlist by 
>> Implementation of ARIN-2019-16" as a Draft Policy.
>> 
>> Draft Policy ARIN-2020-2 is below and can be found at:
>> 
>> https://www.arin.net/participate/policy/drafts/2020_2/
>> 
>> 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-2020-2: Grandfathering of Organizations Removed from 
>> Waitlist by Implementation of ARIN-2019-16
>> 
>> Problem Statement:
>> 
>> The implementation of the ARIN-2019-16 Advisory Council Recommendation 
>> Regarding NRPM 4.1.8: Unmet Requests caused some organizations to be 
>> removed from the waiting list that were approved under the old policy’s 
>> eligibility criteria. These organizations should have been grandfathered 
>> when the waitlist was reopened to allow them to receive an allocation of 
>> IPv4 up to the new policy’s maximum size constraint of a /22.
>> 
>> Policy Statement: Update NRPM Section 4.1.8 as follows:
>> 
>> Add section 4.1.8.3 (temporary language in the NRPM to remain until the 
>> policy objective is achieved)
>> 
>> Restoring organizations to the waitlist
>> 
>> ARIN will restore organizations that were removed from the waitlist at 
>> the adoption of ARIN-2019-16 to their previous position if their total 
>> holdings of IPv4 address space amounts to a /18 or less. The maximum 
>> size aggregate that a reinstated organization may qualify for is a /22.
>> 
>> All restored organizations extend their 2 year approval by [number of 
>> months between July 2019 and implementation of new policy]. Any requests 
>> met through a transfer will be considered fulfilled and removed from the 
>> waiting list.
>> 
>> Comments:
>> 
>> Timetable for implementation: Immediate
>> 
>> Anything Else: While attending ARIN 44 and discussing this with other 
>> community members the vast majority indicated that they agreed that some 
>> organizations were treated unfairly. This proposal is a remedy.
>> ___
>> 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.
> 
> Notice 
> This communication is intended to be received only by the individual[s] or
> entity[s] to whom or to which it is addressed, and contains information
> which is confidential, 

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

[Chris Woodfield]

I support as written, but agree that the word can be removed from the proposal 
without changing its intent, so happy to see it removed.

-Chris

> On May 14, 2020, at 9:49 AM, Owen DeLong  wrote:
> 
> I don’t construe it that way, but I have no objection to either of Scott’s 
> suggestions, either.
> 
> My concern is for the end effect of the proposed policy which is the same 
> with any of the proposed wordings.
> 
> Owen
> 
> 
>> On May 14, 2020, at 09:10 , Scott Leibrand > > wrote:
>> 
>> "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 mailto:i...@arin.net>> 
 > 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, 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Chris Woodfield]

I’ll admit to having skimmed some of this thread, so apologies in advance if 
I've missed prior discussion of the point below.

The guidance against assigning /48s by default described in RFC6177 made sense 
at the time, particularly for an individual residential subscriber site, given 
the assumption that a residential site would rarely, if ever, have a second 
layer of L3 forwarding beyond the broadband router - that is, each /64 within 
the customer’s allocation would be attached to the edge gateway (i.e. multiple 
VLANs, WiFi SSIDs with L3 separation, etc.) In that world, allowing 65K unique 
/64s gateways to exist on a home broadband router was rightly seen as 
unnecessarily wasteful, regardless of sparse addressing design patterns. As is, 
even the 256 /64 prefixes in the /56 I can route to my broadband edge device 
seems like overkill, and I’d like to think I’m much savvier than the typical 
residential subscriber :)

That said, RFC8273, published 6 years after 6177, now recommends that instead 
of assigning individual /128s to hosts within a shared /64, prefix delegation 
should be utilized instead to assign a /64 *per host* by default within an IPv6 
network. This practice unlocks the ability for any end host to become a 
downstream “virtual” L3 router, allowing individually addressed software 
components to be uniquely addressed within a host (obvious candidates here 
would be virtual machines and docker containers, but also individual servers or 
clients living on the host), all numbered from a /64 with a known physical* 
location for policy/security purposes.

Given this recommendation, I believe it absolutely makes sense now to 
standardize as best practice the default assignment of a /48 to even 
residential subscribers, given that IETF-codified best practices now recommend 
exactly that two-layer routing model that the lack of which provided the 
original justification for RFC6177. 

(Side note: Happy to work with any interested parties on a new RFC re-codifying 
the recommendations from RFC3177, informed by 8273, and obsoleting 6177 given 
the above).

Thanks,

-Chris

*Yes, I’m aware the host itself could be virtual as well. Turtles all the way 
down, folks.

> On Apr 19, 2020, at 10:28 AM, John Santos  wrote:
> 
> Policy should not prohibit doing what many regard as best practice.  Just 
> because SOME ISPs might find a /48 unnecessarily large doesn't mean that ALL 
> will, or that the recommendation of a /48 is always WRONG and that nano-ISPs 
> should be punished (financially) for doing so.
> 
> There is obviously a huge scaling issue with fees, when a giant ISP is paying 
> less than a penny per year for addresses and a very small ISP is paying close 
> to a dollar per year, but I don't think we can fix that with policy.  But we 
> can make it less worse by allowing the tiniest ISPs to allocate what they 
> need and not orders of magnitude more than they need at exponentially larger 
> cost.
> 
> Is there any way to ensure that an ISP requesting a /40 has fewer than 250 
> customers, so they can assign each a /48 in order to be eligible for the 
> smallest allocation at commensurate cost with a /24 of IPv4?
> 
> On 4/19/2020 11:33 AM, Fernando Frediani wrote:
>> On 19/04/2020 05:07, Owen DeLong wrote:
>>> 
>>> Right… IETF designed a good architecture and then came under pressure from 
>>> a bunch of people with an IPv4 mindset and given the modern state of the 
>>> IETF decided to just punt on the whole thing rather than waste more time on 
>>> an argument where people were determined to do what they were going to do 
>>> anyway. RFC 6177 is more of a cop-out than a legitimate standards document.
>> We cannot just choose the RFCs we will follow from those we like and 
>> disregard those which we don't. Imagine if vendors start to do the same !
>> Since it correctly (in my view) does putting that /48 for residential 
>> customers should be treated as an exception therefore no RIRs should have to 
>> adapt their policies to it. If ISPs assign /48 to these customers in 
>> exceptional basis (not as default) then they would have less or none of of 
>> the problems discussed here.
>> 
>> 
>> 
>>> 
>>> There’s absolutely noting in RFC6177 that says /48s should not be given out 
>>> to residential customers. It punts it to the operational community and says 
>>> it really shouldn’t
>>> be up to the IETF. That’s generally true, but that does come with a 
>>> responsibility that the operational community doesn’t arbitrarily create 
>>> negative impacts without good
>>> reason.
>> One of the main points of the document, if not the most, is that /48 is no 
>> longer the default and not recommended as well. Therefore if it still 
>> possible to assign to a residential customer it should then be considered an 
>> exception not a normal thing as the others.
>> Let me quote an important part of it within section 2: "Hence, it is 
>> strongly intended that even home sites be given multiple subnets 

Re: [arin-ppml] ARIN 2019-13

[Chris Woodfield]

One could argue that the enforceability of that revocation alone could be 
problematic if the non-domestic entity is able to get a local injunction in 
their home country against it. It is indeed questionable as to whether or not 
*that* injunction would be enforceable in the United States, but there’s always 
the risk of ARIN representatives being held liable should they travel to the 
issuing country. And don’t forget, ARIN staff, board, and AC members regularly 
travel to quite a number of foreign countries on official business (I’m typing 
this from RIPE79 in Rotterdam, for example…), so this risk may not be as 
theoretical as one would assume.

-C

> 
> I am mixed on this.  While most that keep their numbers under this proposed 
> draft will never need to be sued to compliance, that still remains a risk. 
> Maybe some kind of an additional signed agreement with these parties that if 
> the out of area ARIN party fails to act on ARIN action that the resources are 
> automatically revoked without court order could be the stick to still allow 
> this proposal to happen.  Actually it seems to me like such corner case that 
> will be rarely used such that is it worth the effort to do it? Does the 
> proposer advancing this because of specific parties who need it?
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> On Wed, 16 Oct 2019, William Herrin wrote:
> 
>> On Wed, Oct 16, 2019 at 4:16 PM Amy Potter  wrote:
>>  We received a staff and legal assessment for ARIN 2019-13 ARIN 
>> Membership Legal Jurisdiction requirement a bit ago that presented some 
>> serious concerns
>>  about adopting this policy. Based on these concerns I plan to move to 
>> abandon this policy. Just wanted to give the community an opportunity to 
>> voice their
>>  opinions one last time. 
>> Hi Amy,
>> It seems to me that the policy proposal has not been developed to the point 
>> that it's the best policy it can be. I don't (currently) think it's a good 
>> idea but unless
>> everybody else feels the same way (don't think it's a good idea) I'd like to 
>> see the idea fully developed before making a firm choice to support or 
>> oppose it.
>> 
>>  The policy proposal text is included at the end as a refresher.
>> Here were the legal assessment comments:
>> • There are significant material legal concerns regarding adoption of this 
>> policy.
>> To date, entities receiving addresses from ARIN have an ARIN region 
>> incorporation. This is important, as it has permitted ARIN to send 
>> correspondence or make
>> legal service in its region to the entities it is servicing. The proposed 
>> policy would reverse 21 years of practice and experience and require ARIN 
>> accept the
>> necessity to potentially serve legal papers via a foreign legal forum and 
>> litigate in non-region countries. Such foreign legal forums may be located 
>> in some
>> of the countries not committed to the rule of law which is prevalent in our 
>> region, and before foreign courts or tribunals which are hostile to foreign 
>> business
>> interest and/or where the legal system may be expensive and unresponsive.  
>> In addition, the capability for ARIN to know its customer will be 
>> substantially
>> reduced for out of region companies with no in-region domiciled entity.   
>> Considering the legal risks that would result from the proposed policy, 
>> counsel has
>> serious concerns and would advise against adoption unless it is shown that 
>> ARIN has clear and pressing need for adoption to fulfill its mission. 
>> This analysis isn't making much sense to me. Perhaps counsel could clarify?
>> As I recall, the contract (RSA) demands that the registrant accept legal 
>> jurisdiction in Virginia. Does counsel suggest that the contract would 
>> change based on this
>> policy's adoption or that out-region registrants would be released from the 
>> requirement to sign it? If the contract remains unaltered, how would ARIN 
>> become subject
>> to foreign legal forums?
>> This could be perfected with a -business requirement- (not number policy) 
>> that ARIN registrants accept legal service within the ARIN region. That's 
>> slightly more than
>> renting a post office box, but not much. And hiring someone to receive legal 
>> service on your organization's behalf is quite commonplace, at least in the 
>> United
>> States. Certainly a reasonable ask as a part of the proposed policy.
>> Some hyperbole going on in the "reverse 21 years" thing since for much of 
>> that 21 years ARIN's practice included managing addresses for Africa and the 
>> rest of the
>> Americas. Somehow it survived...
>> Finally, as noted in a prior email, counsel is mistaken: many entities 
>> holding ARIN resources are not "incorporated" (to the legal meaning of the 
>> word) anywhere, let
>> alone in the ARIN region. I'm trying not to be pedantic here but some words 
>> have precise legal meanings.
>> Regards,
>> Bill Herrin
>> --
>> William Herrin
>> 

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

[Chris Woodfield]

John - this policy proposal does not prevent an organization from receiving 
resources from the wait list under section 4.1.8 and subsequently doing an 8.2 
transfer of other resources afterwards; it only prohibits a 4.1.8 wait list 
application subsequent to doing an outbound 8.2 transfer.

It’s also OK per the policy to transfer resources after one has applied to 
space under 4.1.8, but before receiving that allocation - it only prevents the 
*application* under 4.1.8, as the actual receipt of resources could (and 
usually does) happen years afterwards.

Let me know if this clarification changes your position on the proposal.

Thanks,

-Chris

> On Jul 29, 2019, at 12:35 PM, John Santos  wrote:
> 
> I generally support the goal of this proposal, but I wonder if a one-time 
> exception should be carved out for and organization which is switching to 
> IPv6, no longer needs a large IPv4 allocation or assignment, and wishes to 
> replace it with a new, much smaller distribution?  Would they be able to 
> apply for and receive a new IPv4 /24 from the wait list, transfer market or 
> the special IPv6 pool, and then sell their existing space under 8.2?  Or 
> would they run afoul of the timing requirements of the proposed wording?  If 
> they were permitted to do this, then I support.  (They could obviously carve 
> out a /24 from their existing space and sell the rest, but that would greatly 
> increase fragmentation.)
> 
> On 7/29/2019 11:18 AM, Fernando Frediani wrote:
>> Totally support this draft policy. It makes sense and is fair and logic to 
>> the IP assignment process.
>> 
>> Fernando
>> 
>> On 25/07/2019 13:26, ARIN wrote:
>>> On 18 July 2019 the ARIN Advisory Council (AC) advanced the following Draft 
>>> Policy to Recommended Draft Policy status:
>>> 
>>> Recommended Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request 
>>> Requirements
>>> 
>>> The text of the Recommended Draft Policy is below, and may also be found at:
>>> 
>>> https://www.arin.net/participate/policy/drafts/2019_1/
>>> 
>>> You are encouraged to discuss all Recommended Draft Policies on PPML prior 
>>> to their presentation at the next ARIN Public Policy Consultation (PPC). 
>>> PPML and PPC discussions are invaluable to the AC when determining 
>>> community consensus.
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> Recommended Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request 
>>> Requirements
>>> 
>>> AC assessment of Conformance with the Principles of Internet Number 
>>> Resource Policy:
>>> 
>>> "This Draft Policy is is fair, impartial, and technically sound. This draft 
>>> policy is an attempt to clarify the waiting period to only prohibit 
>>> requests for IPv4 allocations under Section 4 of the NRPM.
>>> 
>>> Additionally, it disallows organizations that have transferred space to 
>>> other parties within the past 36 months from applying for additional IPv4 
>>> space under NRPM Section 4."
>>> 
>>> 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 

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

[Chris Woodfield]

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.

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

[Chris Woodfield]

Hello,

I support the policy change. I’m confident that given the current state of 
things, this set of changes represent sufficient safeguards that would be 
needed to unblock the issuance of resources under 4.1.8. I’m also confident 
that once we’ve gotten over this hurdle, further refinements can and will be 
made via the normal PDP process. And we’ve already seen that the Board of 
Trustees is empowered and willing to act quickly when necessary should urgent 
changes be made, which gives me further confidence that this is the correct 
approach.

Thanks,

-Chris

> On Jun 6, 2019, at 10:20 AM, John Curran  wrote:
> 
> Folks - 
> 
> We’ve had excellent discussion of various options for the revised “Advisory 
> Council Recommendation Regarding NRPM 4.1.8. Unmet Requests"  proposed policy 
> change – some of which is likely to have to further informed folks initial 
> views on the matter (as well as on future policy proposals in this area), but 
> at this time it is fairly important that we receive focused feedback on the 
> revised policy text as written, with due consideration to the discussion that 
> has occurred online. 
> 
> To that end, at this time it would be good to know from everyone: 
> 
> 1.  Are you in favor of ARIN making the policy change specified in the 
> revised  "Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet 
> Requests”  ?
> 
> (“Yes” obviously indicative that you’d like ARIN to proceed with its adoption 
> and resumption of wait list issuance under its revised guidelines, and 
>  “No” being indicative that you’d rather have the suspension of wait list 
> issuance continue unless/until some other policy change in this area reaches 
> consensus.) 
> 
> 2.  If you are not supportive of ARIN making the change specified in the 
> revised "Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet 
> Requests”,
> is there any modification to the proposed policy change that would enable you 
> to support it?
> 
> I would ask that PPML participants take a moment to consider the proposed 
> policy change as written and please reply regarding the questions above. 
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 
> 
>> Begin forwarded message:
>> 
>> From: ARIN mailto:i...@arin.net>>
>> Subject: [arin-ppml] Revised - Advisory Council Recommendation Regarding 
>> NRPM 4.1.8. Unmet Requests
>> Date: 24 May 2019 at 1:04:58 PM EDT
>> To: mailto:arin-ppml@arin.net>>
>> 
>> 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 

Re: [arin-ppml] Of further interest...

[Chris Woodfield]

I’d presume that if the blocks are forfeited to the US government, they will 
then be monetized on the transfer market, like most other forfeited assets; I 
wouldn’t expect them to be locked away*. Might take a while for the blocks to 
fall out of the routing table and actually become usable, however. 

-C

> On May 15, 2019, at 12:27 PM, Douglas Haber via ARIN-PPML 
>  wrote:
> 
> I have reviewed the indictment and it has a forfeiture order in it. It lists 
> the blocks and states that they shall be forfeited to the United States.
>  
> Now, my question is, does that affect ARIN reclaiming the blocks if they are 
> surrendered to the government?
>  
> Douglas Haber
> Managing Member
> Garden State Computing, LLC
> Tel: (973) 636-7350
> www.gardenstatecomputing.com 
> supp...@gardenstatecomputing.com 
>  
> From: ARIN-PPML  On Behalf Of Mike Burns
> Sent: Wednesday, May 15, 2019 3:15 PM
> To: Martin Hannigan 
> Cc: arin-ppml 
> Subject: Re: [arin-ppml] Of further interest...
>  
> I have the indictment as a pdf but I don't think I can attach it on this 
> mailing list. It is public information though.
> I tried to convert it to text with bad results. If you can't find it and want 
> to see it, let me know and I will put it up somewhere and link to it.
>  
>  
>  On Wed, 15 May 2019 14:54:31 -0400 Martin Hannigan  > wrote 
>  
>  
> And PR
>  
> https://www.postandcourier.com/business/charleston-tech-firm-and-its-ceo-are-indicted-for-fraud/article_4ce68788-773c-11e9-845d-d358d719d2df.html
>  
> 
>  
>  
> /lawnchair
>  
>  
>  
> On Wed, May 15, 2019 at 14:44 Mike Burns  > wrote:
> Other shoe dropped yesterday.
> https://ecf.scd.uscourts.gov/cgi-bin/qrySummary.pl?250341 
> 
>  
> 20 counts of wire fraud.
>  
>  
> ___
> 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 ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements

[Chris Woodfield]

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.

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

[Chris Woodfield]

The issue here is that when you combine site overloading via SNI with CGNAT 
becoming much more prevalent on the client side, particularly on mobile 
networks, you wind up with a larger number of TCP sessions concentrated onto a 
few number of source/dst IPs, which means it’s more likely that you can hit the 
limit of 65K sessions between two given IP addresses (I won’t repeat the math 
that was shown earlier in the thread, but it looks solid to me). Most content 
providers really want to avoid this. As such, most website operators explicitly 
want to avoid sharing IPs with other sites.

-C

> On Mar 2, 2019, at 2:55 PM, Ronald F. Guilmette  
> wrote:
> 
>> As for NAT and even web hosting, the 64k port limitation is also an issue 
>> as pointed out by others.
> 
> No, it isn't.  A web server needs one port (80).  A mail server needs one
> port (25).  A name server needs one port (53).  A /24 block provides nearly
> seventeen *million* IPv4 ports for outbound _client_ use, most or all of
> which should actually be migrated over to IPv6 anyway.

___
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-1: Clarify Section 4 IPv4 Request Requirements

[Chris Woodfield]

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.
> 
> On Tue, 26 Feb 2019, ARIN wrote:
> 
>> On 21 February 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-260: 
>> Clarify Section 4 IPv4 Request Requirements" as a Draft Policy.
>> 
>> Draft Policy ARIN-2019-1 is below and can be found at:
>> https://www.arin.net/policy/proposals/2019_1.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-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 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 12 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 may only receive one allocation, assignment, or transfer 
>> every 3 months, but 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.
>> 
>> Proposed new language:
>> 
>> Repeated requests, in a manner that would circumvent 4.1.6 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 less than three months prior, or if the organization has 
>> transferred space to another party under Section 8 less than 12 months 
>> prior. ARIN, at its sole discretion, may 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.
>> 
>> Comments:
>> 
>> This proposal incorporates two related policy goals, combined for 
>> convenience in one proposal as both can addressed via modification of the 
>> same section and sentence of the NRPM. These policy goals are severable if 
>> the community prefers to address them independently.
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe 

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

[Chris Woodfield]

IMO the PDP is designed to allow for incremental progress on these issues. As 
such, I disagree that a proposal should be abandoned because it’s not a 
panacea. As David has said in the past, ARIN’s mission is stewardship, which 
requires a balance between curbing abuse and allowing the resources to be used 
by the community with minimal friction. I believe that this policy change will 
lessen the incentive and impact of such abuse (ergo, raising the costs which 
effectively reduces the profit motive) while having a minimal impact on the 
operational community.

If the community desires a fundamental rethinking of how ARIN allocates 
resources from the waiting list, other options are on the table. In the 
meantime, I’m in support of this change to the existing policy.

Thanks,

-Chris

> On Mar 2, 2019, at 10:27 AM, Robert Clarke  wrote:
> 
> Sure it definitely cuts down on the abuse, but that isn’t good enough. I 
> don’t think we should support a policy that cuts out “most” of the abuse. 
> 
> If there are other community members interested in co-authoring a policy for 
> ARIN auctioning space, please give me a ping.
> 
> Best Regards,
> 
> Robert Clarke
> CubeMotion LLC
> rob...@cubemotion.com 
> M: +1 (844) 244-8140 ex. 512
> 300 Lenora Street #454, Seattle, WA, 98121
> 
>> On Mar 2, 2019, at 10:16 AM, hostmas...@uneedus.com 
>>  wrote:
>> 
>> This proposal is to lower the maximum to a /22.  I believe that this is 
>> justified to make the waiting list process serve mainly smaller players. 
>> While the /22 size will still allow abuse, it clearly does make it harder on 
>> the abusers versus the current policy.  Changing the waiting list process to 
>> an auction process is something that I think will require drafting a 
>> different Draft Policy, and may have to address many other related matters 
>> that have been discussed.
>> 
>> When a Draft Policy to auction the waiting list space is proposed and 
>> appears on the list, I will likely support it.  However it is much out of 
>> scope for this Draft Policy, whose main feature is to make the maximum 
>> waiting list block size a /22.
>> 
>> If you think an auction is best, draft a policy and lets see how that idea 
>> is accepted.
>> 
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>> 
>> On Sat, 2 Mar 2019, Robert Clarke wrote:
>> 
>>> Hi Albert,
>>> 
>>> As has been discussed previously in this thread, /22 requests still leave a 
>>> serious disincentive problem on the table which is counter-productive in 
>>> the community. Bad actors are incentivized to create multiple shell 
>>> companies to hoard space. In my opinion we should work to come up with an 
>>> alternative solution that puts the incentives back in alignment such as 
>>> allowing ARIN to auction off the space for market rates.
>>> 
>>> While ARIN hands out free money in the form of IPv4 under existing policies 
>>> there will always be a problem with fraud in this community.
>>> 
>>> Best Regards,
>>> 
>>> Robert Clarke
>>> CubeMotion LLC
>>> rob...@cubemotion.com 
>>> M: +1 (844) 244-8140 ex. 512
>>> 300 Lenora Street #454, Seattle, WA, 98121
>>> 
 On Mar 2, 2019, at 9:27 AM, hostmas...@uneedus.com wrote:
 
 I think that changing the waiting list limit to a /22 has merit, even when 
 NOT considering those gaming the system and support the proposal.
 
 I think of the waiting list process is more for the benefit of the smaller 
 player, and making the limit a /22 is consistent with this.
 
 Those that are larger and seeking larger blocks can more aptly afford to 
 hire a broker, or exert internal resources to finding IPv4 space.
 
 I was looking thru the recent transaction list, and I can see that 
 people/brokers have been quite creative in finding space.  I found a 
 couple of instances of smaller colleges who received a class B who have 
 decided to sell off the top half of that space. Since they were likely 
 already behind NAT with the student network and may have never actually 
 used that upper block of numbers, this allows them to make some needed 
 cash for other needs.  Even some of the class A networks like the US 
 Postal Service do not seem to have exposed to the internet anything except 
 the lowest ranges of their allocation, and I guess once the "Price is 
 Right" some of this space may move as well.
 
 Since it has been over 8 years since the official exhaust of IPv4 at the 
 meeting in Miami, I believe that new actors should be instead of using the 
 transfer list to get space should be using the IPv6 deployment block. 
 Since every major OS already has IPv6 support baked in for many years, 
 those setting up new are fools not to be using IPv6 as well. ARIN should 
 do all it can in its policies to promote IPv6.
 
 Setting the waiting list 

Re: [arin-ppml] Revised - Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments

[Chris Woodfield]

Hello,

Given the revision to this Draft Policy listed below, the AC is seeking 
community feedback on the revised policy text. Based on the initial discussion 
re: the original text, the following questions are key:

- Is this problem statement relevant in light of the editorial change under 
consideration by the ARIN Board (formerly ARIN-2017-11)? 
https://www.arin.net/policy/proposals/2017_11.html 


- Does the removal of specific use cases not considered assignments result in 
workable text, or does the community feel that the new language is too broad? 

Thanks,

-Chris

> On Jul 16, 2018, at 11:45 AM, ARIN  wrote:
> 
> The following has been revised:
> 
> * Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments
> 
> Revised text is below and can be found at:
> https://www.arin.net/policy/proposals/2018_4.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-4: Clarification on IPv6 Sub-Assignments
> 
> Problem Statement:
> 
> When the policy was drafted, the concept of assignments/sub-assignments did 
> not consider the use of IP addresses in hotspots, or the use of IP addresses 
> by guests or employees in Bring Your Own Device (BYOD) and many other similar 
> cases.
> 
> Additionally, the IETF has recently approved the use of a unique /64 prefix 
> per interface/host (RFC8273) instead of a unique address. This, for example, 
> allows users to connect to a hotspot, receive a /64 such that they are 
> "isolated" from other users (for reasons of security, regulatory 
> requirements, etc.) and they can also use multiple virtual machines on their 
> devices with a unique address for each one (within the same /64).
> 
> Section 2.5 (Definitions/Allocate and Assign), explicitly prohibits such 
> assignments, stating that "Assignments... are not to be sub-assigned to other 
> parties".
> 
> This proposal clarifies this situation in this regard and better define the 
> concept, particularly considering new uses of IPv6 (RFC8273), by means of a 
> new paragraph.
> 
> Note that the proposal text also incorporates changes made under an Editorial 
> Change currently awaiting Board of Trustees review, available here: 
> https://www.arin.net/policy/proposals/2017_11.html
> 
> Policy Statement:
> 
> Actual Text, Section 2.5:
> 
> •Assign - To assign means to delegate address space to an ISP or 
> end-user, for specific use within the Internet infrastructure they operate. 
> Assignments must only be made for specific purposes documented by specific 
> organizations and are not to be sub-assigned to other parties.
> 
> New Text:
> 
> •   Assignment - Address space delegated to an organization directly by ARIN 
> for the exclusive use of the recipient organization. A temporary assignment 
> of address space provided to third parties shall not be considered an 
> assignment.
> 
> Comments
> 
> Timetable for implementation:
> 
> Immediate
> 
> Anything else:
> 
> Situation in other regions:
> 
> This situation, has already been corrected in RIPE, and the policy was 
> updated in a similar way, even if right now there is a small discrepancy 
> between the policy text that reached consensus and the RIPE NCC Impact 
> Analysis. A new policy proposal has been submitted to amend that, and the 
> text is the same as presented by this proposal at ARIN. Same text has also 
> been submitted to AfriNIC, LACNIC and APNIC.
> ___
> 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-3: Remove Reallocation Requirements for Residential Market Assignments

[Chris Woodfield]

+1 Support as written. Eliminating unnecessary conditions/carve-outs for 
specific use cases goes a long way towards the overall goal of simplifying the 
NRPM. 

-C

> On Apr 23, 2018, at 12:21, ARIN  wrote:
> 
> On 18 April 2018 the ARIN Advisory Council (AC) accepted "ARIN-prop-253: 
> Remove Reallocation Requirements for Residential Market Assignments" as a 
> Draft Policy.
> 
> Draft Policy ARIN-2018-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2018_3.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-3: Remove Reallocation Requirements for Residential 
> Market Assignments
> 
> Problem Statement:
> 
> Current number policy requires some organizations to create reallocations or 
> reassignments for residential subscribers.  This requirement complicates 
> record keeping for ISPs.  There is limited value today for requiring these 
> records be put into the ARIN database.
> 
> ARIN number policy for a long time has required ISPs to add a reallocation or 
> reassignment record for each of their subscriber address blocks.  This policy 
> dates from the original cable allocations as a method to publicly show that a 
> portion of a larger block has been put into use.
> 
> Since ARIN no longer has a free pool of IPv4 addresses and requirements for 
> transfer are demonstrated without these records, this requirement is no 
> longer needed.
> 
> Furthermore, this requirement complicates reallocation & reassignment entry 
> into the ARIN database.3  Removing this requirement could reduce the 
> complexity required for accurately maintaining reallocation and/or 
> reassignment records.
> 
> Policy statement:
> 
> Remove Section 4.2.3.7.3.1 (Residential Market Area) from the 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.
> 

___
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-4: Clarification on IPv6 Sub-Assignments

[Chris Woodfield]

The two terms, from my reading, are synonymous but carry different 
implications, with the term “non-permanently” implying a longer period of time 
than “temporarily". In practice, It will most likely be a distinction built 
into how addresses are assigned by the organization (i.e. static or dynamic 
assignment); would using that as our distinction be a useful avenue to explore?

-C

> On May 10, 2018, at 8:07 AM, JORDI PALET MARTINEZ 
>  wrote:
> 
> When I first used “temporarily” in a preliminary version of the proposal, I 
> was argued that it is not clear then if it is “minutes, hours, days, …”, so 
> non-permanently, looks like clearer in that sense … It may be a matter of not 
> being native English speaker.
>  
> 
> Regards,
> Jordi
> 
>  
> 
>  
> De: ARIN-PPML  en nombre de John Santos 
> 
> Fecha: jueves, 10 de mayo de 2018, 15:01
> Para: 
> Asunto: Re: [arin-ppml] Draft Policy ARIN-2018-4: Clarification on IPv6 
> Sub-Assignments
>  
> I find the word "temporarily" even more obvious than "non-permanently".  If 
> those two words don't mean the same thing, then we definitely need a 
> definition.
> 
>  
> On 5/10/2018 5:08 AM, JORDI PALET MARTINEZ wrote:
>> What will be your opinion if I amend this proposal, so it works for both 
>> IPv4 and IPv6, having this text in section 2.5 (Allocate and Assign), make 
>> it shorter and more generic:
>>  
>> “A unique IPv4 or IPv6 address or a unique IPv6 /64 prefix, which is 
>> non-permanently provided to third parties, shall not be considered an 
>> assignment”
>>  
>> Alternatively, if we don’t want to go so far as to define the “size”:
>>  
>> “An IPv4 or IPv6 block of address, which is non-permanently provided to 
>> third parties, shall not be considered an assignment”
>>  
>> I didn’t found short-term defined in the NRPM. Do you still think we need to 
>> define “permanently” ? I think saying non-permanently it is quite obvious, 
>> but maybe folks disagree …
>> 
>> Regards,
>> Jordi
>> 
>>  
>> 
>>  
>> De: ARIN-PPML  
>>  en nombre de Jo Rhett 
>>  
>> Fecha: miércoles, 9 de mayo de 2018, 20:37
>> Para:  
>> CC:  
>> Asunto: Re: [arin-ppml] Draft Policy ARIN-2018-4: Clarification on IPv6 
>> Sub-Assignments
>>  
>> "Nominative, verb indirect" isn't English ;) Clean english structure would 
>> be:
>> 
>> " <>A unique address or a unique /64 prefix that is non-permanently provided 
>> to third parties shall not be considered an assignment. "
>> 
>> Or if you really want a descriptive phrase that modifies the nominative you 
>> can get commas like so:
>> 
>> 
>> 
>> "A unique address or a unique /64 prefix, which is non-permanently provided 
>> to third parties, shall not be considered an assignment."
>> 
>> I would also argue that this phrase is very vague unless "permanently" is 
>> defined elsewhere in the document. Wasn't there some phrasing around 
>> short-term assignment? (sorry, too busy/too lazy to grab the entire doc 
>> right now)
>>  
>> On Fri, May 4, 2018 at 6:40 PM Andrew Dul > > wrote:
>>> I'd like to suggest that the proposed policy text be shorted and clarified. 
>>>  I don't believe all the examples are necessary in the definition section.
>>> 
>>> Add to the end of NRPM Section 2.5 - 
>>> https://www.arin.net/policy/nrpm.html#two5 
>>> 
>>> 
>>> Current draft text: 
>>> 
>>> The fact that a unique address or even a unique /64 prefix is 
>>> non-permanently provided to third parties, on a link operated by the 
>>> original receiver of the assignment, shall not be considered a 
>>> sub-assignment. This includes, for example, guests or employees (devices or 
>>> servers), hotspots, and point-to-point links or VPNs. The provision of 
>>> addressing for permanent connectivity or broadband services is still 
>>> considered a sub-assignment. Only the addressing of the point-to-point link 
>>> itself can be permanent and that addressing can't be used (neither directly 
>>> or indirectly) for the actual communication. 
>>> 
>>> My suggested rewrite:
>>> 
>>> A unique address or a unique /64 prefix that is non-permanently provided to 
>>> third parties, shall not be considered an assignment. 
>>> 
>>>  
>>> 
>>> On 4/24/2018 11:57 AM, David Farmer wrote:
 I note that the text in question is the subject of an editorial change 
 that the AC has recently forwarded to Board for review, at a minimum the 
 policy text need to be updated to account for this editorial change. 
 Further, I do not support the text as written.
 
 I support a change to section 2 that is not quite so IPv6 specific and 
 focused more on the 

[arin-ppml] Spam replies to PPML posts?

[Chris Woodfield]

Hi,

After sending a comment earlier to the PPML, I’ve been receiving several 
replies to my email (5 at last count) that are obviously spam, but make it past 
my email filters, I’m assuming due to the fact that they’re replies to an email 
I sent. I’m also assuming that the actual sending party is a PPML subscriber, 
since my message hasn’t appeared in the archives yet.

Has anyone else experienced this? Could ARIN staff check for “questionable” 
recent subscriptions to PPML if this is a new thing? I’m happy to share these 
with anyone interested in investigating, albeit with a NSFW warning attached.

Thanks,

-Chris
___
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

[Chris Woodfield]

This is one unavoidable issue with this proposal. ISPs will effectively be 
forced into a workflow where a ISP must allocate addresses and submit the SWIP 
prior to routing the block, and then not start routing until the POC is 
validated, unless ISPs want to risk customer impact/ire from having to withdraw 
the routing 10 days afterwards should the POC not complete the validation.

Personally, I consider this a positive change in process, but those actually 
handling customer turnups are welcome to disagree.

-C

> On Apr 18, 2018, at 12:48 PM, Delacruz, Anthony B 
>  wrote:
> 
> The reject will likely alert us but my systems are not setup to wait 10+ day 
> and then have to go sort out fixing it. I’m worried this is probably going to 
> break some of that. Legacy Centurylink going back thru the Qwest side have 
> done a pretty good job of submitting to whois, other companies we have 
> purchased not so well and we’re working to improve that but it’s a constant 
> battle of staff and use of time. We won’t allocate folks to go chase down 
> customers to click off approval. Asking to do on the phone also not likely as 
> a great many of offerings are moving to more automation. We have entire 
> service classes that can be ordered online, instantly provisioned and 
> activated and then the customer plugs into a prewired/fiber’d port never once 
> interacting with a human. Concerned about both 10 limbo and the loss of info 
> that might be a lead for LEO’s at the very least. I’ve used at least company 
> name and phone number 100’s of times when the poc was old outdated as a 
> starting point in trying to reach folks for issues it would be unfortunate 
> not to have at least.
>  
> From: Jason Schiller [mailto:jschil...@google.com 
> ] 
> Sent: Wednesday, April 18, 2018 9:01 AM
> To: Delacruz, Anthony B
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon 
> Reassignment
>  
> Anthony,
>  
> I hear you.  And I think we should try a "lets do better" approach.
>  
> I think the goal here is to get good SWIP data, and make sure the 
> contact info is correct.
>  
> This specific approach is an attempt to prevent a SWIP targeting
> a (wrong) unwitting victim.  
>  
> In your case I believe you are suggesting you collected the proper 
> contact info, and explained it will be included in the SWIP, and 
> verified that they don't have a pre-existing OrgID or POC, to
> SWIP to.  But then they drop the ARIN email.  And the SWIP
> gets rejected.
>  
> Rejected SWIPs from email templates get an email
> from ARIN Hostmaster >
> with a subject including --REJECTED
>  
> Is this sufficient for you to track down the 
> customers who didn't ack, and fix this issue?
>  
> Is there a better way to loop the ISP back in
> and unwedge the stuck request?
>  
> Would an ARIN Online page of here are all the SWIPs
> that cannot be SWIP'd due to pending ACK help?
> A button to resend the request (while your customer 
> is on the phone)?  
>  
> Are you concerned about the 10 days it is in limbo?
> Or the long term stuff that never gets acked?
>  
> __Jason
>  
> On Tue, Apr 17, 2018 at 4:54 PM Delacruz, Anthony B 
> > 
> wrote:
> Howdy folks I very much hope I’m not a significant part of this problem but 
> we do submit 50-100 reassigns a week. If there is any evidence of us causing 
> trouble in the data I’d be happy to try to run it down and improve. As noted 
> by others we do this primarily to offload abuse but also to assist LEO’s and 
> to be upfront with the community how our space is being use. We also try as 
> hard as we can to populate those records with valid info and have our sales 
> guys collect and input into our system then the provisioning team validates 
> at turn up and the system auto generates at activation the record. I worry 
> greatly that if an entry we send up goes unvalidated for 10 days that it must 
> be deleted. I think you are going to be losing a lot of good data of legit 
> usage simply because folks maybe too lazy to click off on an acknowledgment. 
> If implemented I could be sending all these updates and not seeing them 
> appear and wondering till 10 days down the road which ones I have to 
> reattempt? Will there be a notification back that the record did not 
> populate? That reattempt piece will be a lot of fun to workout with our IT 
> guys I can tell you it’ll just be dropped for a long time until they work out 
> the code to automate and thus usability of whois will be impacted.
>  
>  
> Anthony Delacruz
> Senior Lead Engineer
> IP Admin Backbone Planning and Design
> Office: +1 703 363 8503
> anthony.delac...@centurylink.com 
> ipad...@centurylink.com 
>  
>  
>  
> From: ARIN-PPML 

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

[Chris Woodfield]

And I’d point to the evidence of a transfer market specifically for 16-bit ASNs 
as good evidence of this.

That said, I’d like to understand better the relative imbalance of supply and 
demand for these resources in the various RIR regions before I form a 
conclusion as to whether that imbalance justifies a policy change to resolve.

-C

> On Feb 6, 2018, at 12:39 PM, Job Snijders <j...@instituut.net> wrote:
> 
> On Tue, Feb 06, 2018 at 10:27:55AM -0800, Chris Woodfield wrote:
>> RFC8092 was published roughly a year ago. I can’t imagine that we’ll
>> see universal support for it anytime soon, and there’s plenty of gear
>> out there on the internet today that won’t be getting a software
>> update to support it. 
> 
> It'll be end of 2018 for general available software on the majority of
> platforms - and for a company like NTT, a deployment of configurations
> that use large community are likely to be in 2019 or maybe even 2020.
> I don't intend this statement as a roadmap announcement, but rather to
> illustrate the timescale.
> 
> I'm tracking large community support here: 
> http://largebgpcommunities.net/implementations/
> 
>> I have encountered exactly this scenario, albeit on a private network,
>> but I can’t imagine this not being a real-world issue for multiple
>> operators with public 32-bit ASNs.
> 
> yes, there are real-world issues for 32-bit ASN users today related to
> communities. If I'd have to do a greenfield deployment of a new transit
> network today, using a 16-bit ASN would be a blocking requirement due to
> BGP communities. I imagine that for a number of years to come 16-bit
> ASNs will be more desirable than 32-bit ASNs.
> 
> Kind regards,
> 
> Job
> 

___
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] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers

[Chris Woodfield]

RFC8092 was published roughly a year ago. I can’t imagine that we’ll see 
universal support for it anytime soon, and there’s plenty of gear out there on 
the internet today that won’t be getting a software update to support it. 

I have encountered exactly this scenario, albeit on a private network, but I 
can’t imagine this not being a real-world issue for multiple operators with 
public 32-bit ASNs.

-C

> On Feb 6, 2018, at 10:08 AM, Owen DeLong  wrote:
> 
> 
>> On Feb 6, 2018, at 09:02 , hostmas...@uneedus.com wrote:
>> 
>> I agree that IP addresses and ASN's are not associated with each other to 
>> the extent that changes in one, must trigger a change in the other.  Thus, I 
>> disagree that an ASN transfer must only occur on "clean" ASNs without any 
>> associated IP networks.
>> 
>> For example, I might have an ASN because I am multihomed.  If at some future 
>> date, I decide that I will from now on only use one upstream, I no longer 
>> require an ASN.  In that case, I could either return or transfer if 
>> permitted my ASN to another organization who needs it, and nothing would 
>> link that transfer to any IP resources that I hold.
>> 
>> Based on comments, it appears that even with the technical progress in 
>> making all the various systems work with a 32 bit ASN, cases still exist 
>> that certain routing features only work properly with a 16 bit ASN.  Thus 
>> the proposal to allow transfers was in part to allow those needing a 16 bit 
>> ASN to obtain one from someone who is not using it.
> 
> I continue to hear this claim, but so far nobody has actually provided a real 
> example of this.
> 
> With the advent of LARGE communities (not to be confused with Extended 
> communities), even the most pathologically perverse case of this issue has 
> been solved.
> 
>> If we decide to allow ASN transfers in the ARIN region, I do not think it 
>> needs to be linked in any way to IP resource holdings.
> 
> We already allow ASN transfers in the ARIN region. The question at hand is 
> allowing ASN transfers into/out of the ARIN region from/to other RIRs.
> 
> Owen
> 
>> 
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>> 
>> 
>> 
>> On Thu, 1 Feb 2018, Job Snijders wrote:
>> 
>>> On Thu, Feb 01, 2018 at 06:21:06PM +, Roberts, Orin wrote:
 You could, but then IPv6 routing/fragmentation becomes an issue.
>>> 
>>> How so?
>>> 
 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.
>>> 
>>> Why would one delete networks when an ASN is transferred? The IPs were
>>> assigned according to whatever policy was applicable at that moment. IP
>>> prefixes and ASNs are assigned independently from each other, according
>>> to different policices, and as such it is logical that they are
>>> transferable independently from each other.
>>> 
>>> Kind regards,
>>> 
>>> Job
>>> ___
>>> 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-2018-1: Allow Inter-regional ASN Transfers

[Chris Woodfield]

Hi Mike,

I’d consider it very poor argument to promote a policy proposal solely based on 
its adoption in other RIRs. Various RIRs, and the regions they represent, often 
have unique, and sometimes conflicting requirements for management of internet 
resources, and as such we should be evaluating proposals on their merits. 
Adoption by other RIRs is one input for consideration, but should never be the 
primary input.

The Policy Development Process requires that the proposal in question present a 
clear problem statement and come to a consensus as a community that the 
language being proposed solves that statement. As such, we must carefully 
consider both the problem statement, *and* the policy language proposed. This 
is the main motivation for the discussions you’re seeing re: the problem 
statement itself; we simply can’t adopt a policy based on a non-specific 
problem, and a simple apparent lack of downsides of adopting the proposed edit 
to the NRPM. 

As such, on the PPML we’ve seen several viable justifications for this 
proposal; I’d expect at least one, if not both, to eventually find its way into 
a modified problem statement, and once that’s done, we can discuss the proposal 
itself as to whether or not it solves the issue as proposed and the relative 
merits and costs thereof.

Hope this helps,

-Chris

> On Feb 1, 2018, at 8:57 AM, Mike Burns  wrote:
> 
> Hello,
>  
> The transfer logs at APNIC and RIPE indicate that inter-regional transfers 
> have been completed.
> I consider that objective evidence of need for this functionality. 
>  
> Can somebody provide a downside to the approval of this policy?
> Staff work? The heavy lifting has already been provided by APNIC and RIPE.
>  
> Is it important for us to determine every possible reason why people need 
> this functionality?
> Shouldn’t our default position be trying to answer their need unless there is 
> a reason not to?
>  
> Regards,
> Mike
>  
>  
>  
>  
>  
>  
> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of Owen DeLong
> Sent: Thursday, February 01, 2018 11:40 AM
> To: WOOD Alison * DAS 
> Cc: arin-ppml@arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN 
> Transfers
>  
> IMHO, yes.
>  
> For A), I’m not sure I see the need to support these transactions. We don’t 
> support them for IPv6 (nor do I think we want to).
> Sales of IPv4 addresses were a stop-gap to deal with a situation of scarcity, 
> free pool exhaustion, and getting by until v6
> is widely enough deployed. Hopefully they will eventually go away and we can 
> return to more traditional forms of resource management.
>  
> For B), I’m still not convinced. They can’t move their IPv6 resources (nor do 
> I think we want to support doing so). The ability to move their IPv4 
> resources is largely an artifact of the same scarcity/free pool exhaustion 
> described above. However, my objections to solving this particular problem 
> are a bit less than my objections to solving problem A).
>  
> Owen
>  
>> On Feb 1, 2018, at 06:51 , WOOD Alison * DAS > > wrote:
>>  
>> Thank you all for the excellent feedback on this draft.
>>  
>> Considering James’ suggestions, would the community prefer to take each 
>> point as a different proposal?  They seem to be two different solutions to 
>> two different issues.
>>  
>> Thanks!
>>  
>> -Alison
>>  
>> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net 
>> ] On Behalf Of james machado
>> Sent: Wednesday, January 31, 2018 12:47 PM
>> To: arin-ppml@arin.net 
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN 
>> Transfers
>>  
>> So we seem to have 2  "problems" for this draft if I am reading correctly.
>>  
>> A) An Entity wishes to buy/sell/transfer one or more ASN(s) to another 
>> Entity without regard of the destination RIR.  
>>  
>> B) Entity with one or more ASN(s) wishes to move one or more ASN(s) to a new 
>> RIR, possibly complementing an IP move, to begin/continue operations in the 
>> destination RIR.
>>  
>> 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.
> 
>  
> ___
> 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

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

[Chris Woodfield]

Hi David,

Section 4 requests are still relevant for the waiting list and critical 
infrastructure, but little else. That said, there have been efforts in the past 
to obliterate Section 4 wholesale and replace it with a much more concise text, 
but those never had much support. I’d be happy to try again in the name of 
simplification, but that would be an entirely separate proposal.

-C

> On Dec 7, 2017, at 9:37 PM, David Huberman  wrote:
> 
> Thank you for the clarification.  I think the staff practice is a reasonable 
> approach and I don’t think change is needed in policy for this.
> 
> The updated Problem Statement reveals the real issue here - the one we need 
> to figure out as a community.   What to do about all the requests each month 
> for IPv4 addresses under section 4? 
> 
> Is it time to pass a policy to direct staff to no longer accept section 4 
> requests (except the ones they still fill like critical infrastructure)? I 
> wonder what the downside of such a policy would be - anyone know?
> 
> 
> 
> On Dec 7, 2017, at 11:47 PM, Andrew Dul  > wrote:
> 
>> It was noted to me by ARIN staff, that this updated problem statement 
>> doesn't accurately reflect ARIN's current practice.  Below I suggest another 
>> updated problem statement.
>> 
>> 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 qualified 
>> ISPs an initial /21 for Section 8 transfers when they first apply and are 
>> approved under section 4.  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.
>> 
>> 
>> 
>> On 12/4/2017 1:30 PM, Andrew Dul 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 > 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  > wrote:
> 
>> 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 

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

[Chris Woodfield]

One point to make on this proposal is that this may change how ISPs assign 
blocks, given that both transfers and allocations have needs-based policies in 
force (for both v4 and v6), and SWIPs are generally used as evidence of 
utilization of existing blocks. With this proposal in force, adding a SWIP to 
an allocated block should no longer be considered a parallel process to 
assigning space to a downstream customer; instead, the insertion of a SWIP with 
a validated POC will be a blocking function on the downstream allocation, 
otherwise customers will be utilizing blocks without SWIPs if the POC is never 
validated.

IMO this is how I feel the system *should* work, but then again, I’m currently 
not in the business of doing these kinds of assignments. Those who would be 
more directly impacted by this may have a different point of view :)

-C

> On 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-12: Require New POC Validation Upon Reassignment

[Chris Woodfield]

First off, I’m in favor of the goal of this proposal; I’m sure that a large 
percentage of unverified POCs are due to SWIPs being made with POCs that are 
invalid from the get-go. I expect the language will evolve through the PDP, so 
I’ll hold off on my “as written” judgement for the time being.

To your specific suggestion: I’d expect that such a mechanism would be a great 
enhancement to the current validation process, independent of this particular 
policy proposal. It would be great if it was possible to set up rules in the 
ARIN portal that, for example, funneled all POC creation attempts with 
@my.domain as the email address to a specific role account, for example. That 
said, your suggestion defines an implementation mechanism, not a policy, and as 
such, doesn’t belong in the NRPM.

Thanks,

-C

> On Nov 21, 2017, at 4:36 PM, james machado  wrote:
> 
> Generally I support this idea but I would expand on 3.7.  
> 
> In the event that an entity already has an ARIN POC they would have the 
> option of accepting the new POC or utilizing an existing POC at the entities 
> discretion for the reallocation or reassignment.
> 
> I have been in the position of having multiple unknown POCs with ARIN for 
> $dayjob and having them connected random employees depending on whom the 
> salesman spoke too at the time they were filling out the documents.  I want 
> the option to have all the reassignments/reallocations associated with the 
> POCs I choose.
> 
> 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.

___
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

[Chris Woodfield]

I’ll note the existing section text, emphasis mine:

"6.5.5.1. Reassignment information
Each static IPv6 assignment containing a /64 or more addresses *shall* be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2. Reassignment registrations *shall* 
include each client's organizational information, except where specifically 
exempted by this policy.
6.5.5.2. Assignments visible within 7 days
All assignments *shall* be made visible as required in section 4.2.3.7.1 within 
seven calendar days of assignment.”

Guidance from staff on this matter has been discussed before on PPML. For 
example, John Curran’s comment from 9/30/2017:

"  all parties agree to compliance with resource policies in NRPM 
   per provisions in RSA, with revocation being a potential consequence of 
chronic
   non-compliance. “

Are you suggesting that this policy, if implemented, should have specific 
stated penalties for non-compliance that are separate from the general case of 
a party violating any other clause of the NRPM?

-C


> On Oct 12, 2017, at 7:33 AM, Michael Winters  wrote:
> 
> Opposed as written (amended).
> 
> As written, (IMHO) it is an incomplete and unenforceable policy (shall part 
> anyway).
> If you are saying shall, what is the policy for ARIN to follow if there is 
> noncompliance.
> In attempting to fix a potential problem that does not yet exist, due to the 
> word shall, this policy creates a problem.
> 
> Should have stuck with should.
> 
> Thanks,
> Mike
> 
> -Original Message-
> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of ARIN
> Sent: Wednesday, October 11, 2017 3:17 PM
> To: arin-ppml@arin.net
> Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-5: 
> Improved IPv6 Registration Requirements
> 
> 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 

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

[Chris Woodfield]

There was discussion on this topic during the meeting (and prior to the 
meeting, from ARIN staff here on list), with the guidance being that the 
“shall” being proposed here would be enforced similarly to every other 
occurrence of “shall” as it appears in the NRPM; it becomes part of the RSA 
like any other adopted proposal that makes it through the PDP.

Don’t forget that in general, this proposal is a *relaxing* of current terms, 
which currently requires registering *all* static assignments up to /64; the 
keyword in 6.5.5.1 is *already* “shall”.

-C

> On Oct 8, 2017, at 6:18 AM, Dewole Ajao  wrote:
> 
> 
> 
> If I were to guess, "should" would go through and a discussion would be 
> started regarding how to enforce a "shall" in a reasonable manner. 
> 
> My thoughts anyway. 
> 
> Dewole. 
> 
> 
> 

___
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

[Chris Woodfield]

I think we’re talking about the difference between “editorial change” and 
“minor change”. And editorial change, as I understand it, requires no PPM 
consensus, which isn’t what we’re discussing here.

I’d agree with your point that staff would probably be the best arbiters of the 
implementation changes, which would in turn guide as to whether it’s acceptable 
to discuss the word change and move forward at PPM, or to require additional 
consultation if the community consensus is to require the change before 
adoption. Staff has guided on the practical implications of the change; it’s up 
to the community to decide whether or not that’s a desired outcome.

I’d presume that if the proposal is adopted as written, there are several 
people primed to submit a new policy proposal to change “should” to “shall”. 
That, in my opinion, is a very reasonable path forward as well.

-C

> On Sep 28, 2017, at 10:56 AM, Kevin Blumberg <kev...@thewire.ca> wrote:
> 
> Chris, <>
>  
> I have had a difference of opinion in the past, with members of the 
> community, with what constitutes an editorial change. I have always erred on 
> the side of caution.
>  
> While I’m indifferent to the options, I am strongly in support of this policy 
> moving forward.
>  
> If there is a chance that the change will be questioned during last call, and 
> prevent the policy from moving forward, I’m opposed to any alteration.
>  
> I believe that staff have shown significant implementation differences 
> between the two words.
>  
> Some assistance from the Advisory Council and/or Staff to the community as 
> what would constitute an editorial change would probably be helpful.
>  
> Thanks,
>  
> Kevin Blumberg
>  
> From: Chris Woodfield [mailto:ch...@semihuman.com] 
> Sent: Thursday, September 28, 2017 1:21 PM
> To: Owen DeLong <o...@delong.com>; arin-ppml@arin.net
> Cc: Kevin Blumberg <kev...@thewire.ca>
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 
> Registration Requirements
>  
> I agree with Owen’s assessment. If there is sufficient community support for 
> changing the phrase to “shall” at the PPM - I’d define “sufficient community 
> support” as a show of hands on that specific word choice, in addition to the 
> discussion here - I see no need to require another public consultation in 
> order to go to last call incorporating that change in terms.
>  
> I’m personally in favor of “shall", although I still support as written. 
> Perfect as enemy of good, etc etc.
>  
> Thanks,
>  
> -C
>  
> On Sep 28, 2017, at 9:03 AM, Owen DeLong <o...@delong.com 
> <mailto:o...@delong.com>> wrote:
>  
> While I wouldn’t consider it an editorial change, I would consider it a minor 
> change, which, if it had good community discussion and support at the 
> meeting, would, IMHO, be within the scope of pre-last-call changes that could 
> be made between the PPM and last call.
>  
> The AC has, as has been mentioned before, significant discretion in 
> determining what is a “minor change”.
>  
> This is strictly my own opinion and may or may not be shared by other AC 
> members, staff, or anyone else.
>  
> Owen
>  
> On Sep 28, 2017, at 10:46 AM, Kevin Blumberg <kev...@thewire.ca 
> <mailto:kev...@thewire.ca>> wrote:
>  
> I support the policy as written.
>  
> If the stick isn’t big enough it appears a simple policy change could be 
> used, not just for this section but all the other areas “should” is used.
>  
> I would like to point out that “should” is currently used 30 times in the 
> NRPM.
>  
> In reading John’s explanation, I can’t see “should” and “shall” being 
> considered an editorial change. To extend the policy cycle to another meeting 
> would be far worse.
>  
> Out of curiosity, how often has ARIN had to deal with SWIP issues like this, 
> where the other party ignored you?
>  
> Thanks,
>  
> Kevin Blumberg
>  
>  
> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net 
> <mailto:arin-ppml-boun...@arin.net>] On Behalf Of John Curran
> Sent: Wednesday, September 27, 2017 5:59 PM
> To: Jason Schiller <jschil...@google.com <mailto:jschil...@google.com>>
> Cc: arin-ppml@arin.net <mailto:arin-ppml@arin.net>
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 
> Registration Requirements
>  
> On 26 Sep 2017, at 3:18 PM, Jason Schiller <jschil...@google.com 
> <mailto:jschil...@google.com>> wrote:
>  
> I oppose as written.
>  
> There should not be a different standard of requirement for:
> - re-allocation
> - reassignment containing a /47 or more addresses
> - subdelegation of any size that will

Re: [arin-ppml] ARIN-PPML 2017-5

[Chris Woodfield]

Rudolph,

My reading of the proposal is that the registration is triggered by the request 
from the downstream recipient, which implies that if no prior requests have 
been received, then there would be no duty to register. Requests from 
downstreams received after the policy is implemented would be subject to these 
terms.

I’ll agree that this is ambiguous re: requests from downstreams received prior 
to implementation, but in practical terms, I’d expect interested downstreams  
to be aware of the policy change and simply resubmit that request, if the prior 
request was not granted.

Thanks,

-C

> On Sep 28, 2017, at 10:13 AM, Rudolph Daniel  wrote:
> 
> I am in support of the policy proposal with "shall" but I would like to know 
> of possible negative impact if approved as policy; on the past reassignments 
> that were not SWIP ed.
> Is this perceived as an issue; or will the policy be retroactive? Either way.
> 
> 
> Rudi Daniel
> danielcharles consulting 
> 
> 
> 
> 
> On Thu, Sep 28, 2017 at 12:05 PM,  > wrote:
> Send ARIN-PPML mailing list submissions to
> arin-ppml@arin.net 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> http://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: Recommended Draft Policy ARIN-2017-5: Improved IPv6
>   Registration Requirements (Owen DeLong)
>2. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6
>   Registration Requirements (Owen DeLong)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 28 Sep 2017 10:46:01 -0500
> From: Owen DeLong >
> To: John Curran >
> Cc: Jason Schiller >, 
> "arin-ppml@arin.net "
> >
> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5:
> Improved IPv6 Registration Requirements
> Message-ID: <314b3dc2-87ba-434d-9eec-f2bd60f67...@delong.com 
> >
> Content-Type: text/plain; charset="utf-8"
> 
> Given this, I personally think that shall is the better choice of wording for 
> 6.5.5.4.
> 
> Owen
> 
> > On Sep 27, 2017, at 4:59 PM, John Curran  > > wrote:
> >
> > On 26 Sep 2017, at 3:18 PM, Jason Schiller  >   > >> wrote:
> >>
> >> I oppose as written.
> >>
> >> There should not be a different standard of requirement for:
> >> - re-allocation
> >> - reassignment containing a /47 or more addresses
> >> - subdelegation of any size that will be individually announced
> >>
> >> which is "shall"
> >>
> >> and Registration Requested by Recipient
> >>
> >> which is "should"
> >>
> >> I would support if they are both "shall".
> >>
> >> Can ARIN staff discuss what actions it will take if an ISP's
> >> down stream customer contacts them and explains that their
> >> ISP refuses to SWIP their reassignment to them?
> >>
> >> Will they do anything more than reach out to the ISP and tell
> >> them they "should" SWIP it?
> >
> > Jason -
> >
> >If this policy change 2017-5 is adopted, then a provider that has IPv6 
> > space from ARIN
> >but routinely fails to publish registration information (for /47 or 
> > larger reassignments)
> >would be in violation, and ARIN would have clear policy language that 
> > would enable
> >us to discuss with the ISP the need to publish this information in a 
> > timely manner.
> >
> >Service providers who blatantly ignore such a provision on an ongoing 
> > basis will be
> >in the enviable position of hearing me chat with them about their 
> > obligations to follow
> >ARIN number resource policy, including the consequences (i.e. potential 
> > revocation
> >of the IPv6 number resources.)
> >
> >If the langauge for the new section 6.5.5.4 "Registration Requested by 
> > Recipient?
> >reads ?? the ISP should register that assignment?, then ARIN would send 
> > on any
> >received customer complaint to the ISP, and remind the ISP that they 
> > should
> >follow number 

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

[Chris Woodfield]

I agree with Owen’s assessment. If there is sufficient community support for 
changing the phrase to “shall” at the PPM - I’d define “sufficient community 
support” as a show of hands on that specific word choice, in addition to the 
discussion here - I see no need to require another public consultation in order 
to go to last call incorporating that change in terms.

I’m personally in favor of “shall", although I still support as written. 
Perfect as enemy of good, etc etc.

Thanks,

-C

> On Sep 28, 2017, at 9:03 AM, Owen DeLong  wrote:
> 
> While I wouldn’t consider it an editorial change, I would consider it a minor 
> change, which, if it had good community discussion and support at the 
> meeting, would, IMHO, be within the scope of pre-last-call changes that could 
> be made between the PPM and last call.
> 
> The AC has, as has been mentioned before, significant discretion in 
> determining what is a “minor change”.
> 
> This is strictly my own opinion and may or may not be shared by other AC 
> members, staff, or anyone else.
> 
> Owen
> 
>> On Sep 28, 2017, at 10:46 AM, Kevin Blumberg > > wrote:
>> 
>> I support the policy as written. <>
>>  
>> If the stick isn’t big enough it appears a simple policy change could be 
>> used, not just for this section but all the other areas “should” is used.
>>  
>> I would like to point out that “should” is currently used 30 times in the 
>> NRPM.
>>  
>> In reading John’s explanation, I can’t see “should” and “shall” being 
>> considered an editorial change. To extend the policy cycle to another 
>> meeting would be far worse.
>>  
>> Out of curiosity, how often has ARIN had to deal with SWIP issues like this, 
>> where the other party ignored you?
>>  
>> Thanks,
>>  
>> Kevin Blumberg
>>  
>>  
>> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net 
>> ] On Behalf Of John Curran
>> Sent: Wednesday, September 27, 2017 5:59 PM
>> To: Jason Schiller >
>> Cc: arin-ppml@arin.net 
>> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 
>> Registration Requirements
>>  
>> On 26 Sep 2017, at 3:18 PM, Jason Schiller > > wrote:
>>  
>> I oppose as written.
>>  
>> There should not be a different standard of requirement for:
>> - re-allocation
>> - reassignment containing a /47 or more addresses
>> - subdelegation of any size that will be individually announced
>>  
>> which is "shall"
>>  
>> and Registration Requested by Recipient
>>  
>> which is "should"
>>  
>> I would support if they are both "shall".
>>  
>> Can ARIN staff discuss what actions it will take if an ISP's
>> down stream customer contacts them and explains that their
>> ISP refuses to SWIP their reassignment to them?
>>  
>> Will they do anything more than reach out to the ISP and tell
>> them they "should" SWIP it?
>>  
>> Jason - 
>>  
>>If this policy change 2017-5 is adopted, then a provider that has IPv6 
>> space from ARIN 
>>but routinely fails to publish registration information (for /47 or 
>> larger reassignments) 
>>would be in violation, and ARIN would have clear policy language that 
>> would enable 
>>us to discuss with the ISP the need to publish this information in a 
>> timely manner.   
>> 
>>Service providers who blatantly ignore such a provision on an ongoing 
>> basis will be 
>>in the enviable position of hearing me chat with them about their 
>> obligations to follow 
>>ARIN number resource policy, including the consequences (i.e. potential 
>> revocation 
>>of the IPv6 number resources.)
>>  
>>If the langauge for the new section 6.5.5.4 "Registration Requested by 
>> Recipient” 
>>reads “… the ISP should register that assignment”, then ARIN would send 
>> on any
>>received customer complaint to the ISP, and remind the ISP that they 
>> should
>>follow number resource policy in this regard but not otherwise taking any 
>> action.  
>>  
>>If the language for the new section 6.5.5.4 "Registration Requested by 
>> Recipient”  
>>reads “… the ISP shall register that assignment”, then failure to do so 
>> would be
>>a far more serious matter that, if left unaddressed on a chronic manner, 
>> could have 
>>me discussing the customer complaints as a sign of potential failure to 
>> comply with 
>>number resource policy, including the consequences (i.e. potential 
>> revocation of 
>>the IPv6 number resources.)
>>  
>>I would note that the community should be very clear about its intentions 
>> for ISPs
>>with regard to customer requested reassignment publication, given there 
>> is large 
>>difference in obligations that result from policy language choice.   ARIN 
>> staff remains, 
>>as always, looking forward to implementing whatever policy 

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

[Chris Woodfield]

Support as written. Great work everyone on this!

-C

> On 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 admi
 nistrative 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.
> 

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

[Chris Woodfield]

I’d argue the opposite - when crafting policy, we must be precise in our 
language, and in general we must avoid ambiguous terms, unless there’s a 
specific goal to leaving a section of language open for interpretation (and 
even then, it must be clear whose interpretation reigns supreme).

I’m a fan of the term LIR, even if it is somewhat abstract. Language clearly 
linking the two terms, defining an ISP as the most common example of an LIR, 
would be helpful as well.

-C

> On Sep 18, 2017, at 9:48 AM, David Farmer  wrote:
> 
> This has gone back and forth over the years, some people think "LIR" is too 
> abstract and some people think "ISP" is too specific. While ISP doesn't have 
> it's own subsection under definitions it is discussed under "LIR", section 
> 2.5, so I wouldn't say it's undefined. I think it's probably dangerous to 
> make a hard and fast rule either way.  I think it is probably best to think 
> of "ISP" and "LIR" as synonyms, at least from an ARIN policy perspective, but 
> just like many synonyms they have subtly different connotations.
> 
> Thanks.
> 
> On Mon, Sep 18, 2017 at 11:14 AM, John Santos  > wrote:
> 
> 
> On 9/18/2017 10:37 AM, ARIN wrote:
> The following has been revised:
> 
> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
> [snip]
> 
> 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."
> 
> I have been under the impression that a common goal of most people proposing 
> NRPM changes is to eliminate the use of the term "ISP", since it is not 
> defined in the policy and most or all the relevant sections also apply to 
> other organizations that, while they re-allocate or reassign address space, 
> are not, properly speaking, ISPs.  Shouldn't this says "LIR" or "provider" or 
> some other more generic term?
> 
> 
> [snip]
> 
> -- 
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539 
> 
> ___
> 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 SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-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.

___
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] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

[Chris Woodfield]

Replying to myself, I decided to look up the population proportions mentioned 
in my last email:

North America - 7.79%
South America - 5.68%
Africa - 16.36%

So if one were to use numbers similar to these - the average formula doesn’t 
make much of a difference for LACNIC, and actually qualifies AFRINIC for a far 
larger share of space than the straight average. 

I’m wondering what, if any, types of metrics might exist for measuring demand 
for resources instead of population? Or does that run afoul of the concept of 
Internet access as a worldwide human right?

-C

> On Sep 7, 2017, at 2:50 PM, Chris Woodfield <ch...@semihuman.com> wrote:
> 
> Thinking more about the use of an average distribution in the proposal, I’m 
> wondering if this accurately reflects the issue. 
> 
> The distribution of IP addresses by IANA to the various RIRs is only 
> inequitable if it results in a clear difference in the ability of an entity 
> in different regions to acquire IP address space. We don’t need the same 
> number of allocations in each region - if nothing else, the allocations 
> should roughly reflect regional populations - but it should be no more 
> difficult for a party in Africa or South America to acquire IPv4 resources 
> than it is for a party in North America, Europe, or Asia to do so. To the 
> extent that this is not the case, we owe the community action to correct.
> 
> The question then becomes - does the lack of a transfer policy from ARIN to 
> these regions make it substantially more difficult to acquire space on the 
> transfer market today? I’d argue that to the extent that doing so requires 
> transferring to the space to the local RIR, then the answer is YES, as from 
> my point of view, the bulk of transfer market supply is from allocations in 
> the ARIN region (resellers on the list who are in a position to comment, 
> please keep me honest and speak up if that isn’t the case).
> 
> This is somewhat mitigated by the current case that both LACNIC and AFRINIC 
> still have space to allocate, while ARIN does not. But shower term 
> point-in-time facts shouldn’t drive far-reaching policy decisions IMO.
> 
> As such, I support the goal of the policy, but I believe that the calculation 
> used to determine qualifying RIRs could be tweaked. Could we compare 
> allocation percentages to world population, perhaps?
> 
> -C
> 
>> On Sep 7, 2017, at 2:27 PM, Cj Aronson <c...@daydream.com 
>> <mailto:c...@daydream.com>> wrote:
>> 
>> David.. I agree with your very well written summary.  I just feel that the 
>> mathematical formula to determine when the transfers have to start being 
>> reciprocal is not needed.  
>> 
>> The reason why I feel that way is that we're computing something that was 
>> said earlier, "To go below the global average, the RIR above the average and 
>> closest to
>> it would need to lose 81,871,002 more addresses, which at the current rate
>> (14,592 lost per month) would take 5,620 months (468 years)." 
>> 
>> It seems like we're spending time computing something that is not likely to 
>> happen.. I would surely hope we are done with IPv4 within the next 468 years 
>>  :-)   
>> 
>> 
>> Thanks!
>> -Cathy
>> 
>> 
>> {Ô,Ô}
>>   (( ))
>>   ◊  ◊
>> 
>> On Thu, Sep 7, 2017 at 2:46 PM, David Farmer <far...@umn.edu 
>> <mailto:far...@umn.edu>> wrote:
>> Cathy,
>> 
>> Yes, in some ways it would be more straight forward to just say LACNIC and 
>> AFRINIC are allowed an exception to the reciprocity requirement.  However, 
>> that policy would contain only the facts of the situation.  Whereas this 
>> policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted 
>> from the reciprocity requirement and why APNIC and RIPE are not. 
>> 
>> To be honest, I didn't want the reciprocity requirement in the original 
>> transfer policy to being with, because of the optics of this very situation 
>> with LACNIC and AFRINIC.  However, I didn't push the issue with the original 
>> transfer policy because I knew it would be several year before LACNIC and 
>> AFRINIC got to the point of approving a transfer policy of any kind. So, 
>> when this issue with LACNIC and AFRINIC came up I thought obvious thing to 
>> do was to eliminate the reciprocity requirement all together. However, I 
>> really like this compromise as well as the reasoning that comes with it. 
>> 
>> There is absolutely no reason for transfers with APNIC and RIPE to not be on 
>> a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be 
>> room for some nuance. LACNIC and A

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

[Chris Woodfield]

Thinking more about the use of an average distribution in the proposal, I’m 
wondering if this accurately reflects the issue. 

The distribution of IP addresses by IANA to the various RIRs is only 
inequitable if it results in a clear difference in the ability of an entity in 
different regions to acquire IP address space. We don’t need the same number of 
allocations in each region - if nothing else, the allocations should roughly 
reflect regional populations - but it should be no more difficult for a party 
in Africa or South America to acquire IPv4 resources than it is for a party in 
North America, Europe, or Asia to do so. To the extent that this is not the 
case, we owe the community action to correct.

The question then becomes - does the lack of a transfer policy from ARIN to 
these regions make it substantially more difficult to acquire space on the 
transfer market today? I’d argue that to the extent that doing so requires 
transferring to the space to the local RIR, then the answer is YES, as from my 
point of view, the bulk of transfer market supply is from allocations in the 
ARIN region (resellers on the list who are in a position to comment, please 
keep me honest and speak up if that isn’t the case).

This is somewhat mitigated by the current case that both LACNIC and AFRINIC 
still have space to allocate, while ARIN does not. But shower term 
point-in-time facts shouldn’t drive far-reaching policy decisions IMO.

As such, I support the goal of the policy, but I believe that the calculation 
used to determine qualifying RIRs could be tweaked. Could we compare allocation 
percentages to world population, perhaps?

-C

> On Sep 7, 2017, at 2:27 PM, Cj Aronson  wrote:
> 
> David.. I agree with your very well written summary.  I just feel that the 
> mathematical formula to determine when the transfers have to start being 
> reciprocal is not needed.  
> 
> The reason why I feel that way is that we're computing something that was 
> said earlier, "To go below the global average, the RIR above the average and 
> closest to
> it would need to lose 81,871,002 more addresses, which at the current rate
> (14,592 lost per month) would take 5,620 months (468 years)." 
> 
> It seems like we're spending time computing something that is not likely to 
> happen.. I would surely hope we are done with IPv4 within the next 468 years  
> :-)   
> 
> 
> Thanks!
> -Cathy
> 
> 
> {Ô,Ô}
>   (( ))
>   ◊  ◊
> 
> On Thu, Sep 7, 2017 at 2:46 PM, David Farmer  > wrote:
> Cathy,
> 
> Yes, in some ways it would be more straight forward to just say LACNIC and 
> AFRINIC are allowed an exception to the reciprocity requirement.  However, 
> that policy would contain only the facts of the situation.  Whereas this 
> policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted 
> from the reciprocity requirement and why APNIC and RIPE are not. 
> 
> To be honest, I didn't want the reciprocity requirement in the original 
> transfer policy to being with, because of the optics of this very situation 
> with LACNIC and AFRINIC.  However, I didn't push the issue with the original 
> transfer policy because I knew it would be several year before LACNIC and 
> AFRINIC got to the point of approving a transfer policy of any kind. So, when 
> this issue with LACNIC and AFRINIC came up I thought obvious thing to do was 
> to eliminate the reciprocity requirement all together. However, I really like 
> this compromise as well as the reasoning that comes with it. 
> 
> There is absolutely no reason for transfers with APNIC and RIPE to not be on 
> a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be 
> room for some nuance. LACNIC and AFRINIC have received the short-end of the 
> stick, so to speak.  There was no conspiracy or wrongdoing that caused this 
> result, but it is a stark fact when you look at the numbers. I therefore 
> believe these facts should afford LACNIC and AFRINIC some latitude to decide 
> for themselves how best to move forward. 
> 
> In the long-run I totally believe LACNIC and AFRINIC should approve 
> reciprocal transfer policies. However, we need to give them room to decide 
> this for themselves, it is arrogant and inconsiderate of the facts for us to 
> dictate a reciprocal transfer policy to them.  If they feel they need to 
> start with a one-way transfer policy, there is logic to such a strategy, and 
> the current facts seem to justify at least some caution on their part.   
> 
> Finally, the numbers show we have more than enough room to be magnanimous in 
> this situation, I believe we should give LACNIC and AFRINIC room to maneuver, 
> and choose their own way forward. 
> 
> Thanks.
> 
> On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson  > wrote:
> Okay so this formula.. does it just give us Afrinic and Lacnic right?  So why 
> don't we just say that?  Since 

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

[Chris Woodfield]

Which leads to the question as to why… a policy proposal to allow for outbound 
transfers as well as inbound in those regions would render this policy moot. Is 
there any sense of the appetite for such a proposal in either region, or would 
it be perceived as having the potential to result in even more IP space leaving 
those regions (due to deeper pockets in the transfer market in other regions)?

-C

> On Sep 7, 2017, at 11:25 AM, Owen DeLong  wrote:
> 
> Neither LACNIC nor AfriNIC have currently passed or implemented an inter-RIR 
> transfer policy.
> 
> All Inter-RIR policies that have been considered in either region have been 
> unilateral inbound-only to the best of my knowledge.
> 
> Owen
> 
>> On Sep 7, 2017, at 05:30 , Kevin Blumberg  wrote:
>> 
>> Are there active polices in the other regions that rely on this policy? I 
>> understand there have been discussions, however I don't know what the status 
>> is/was. 
>> 
>> Thanks,
>> 
>> Kevin Blumberg
>> 
>> 
>> 
>> -Original Message-
>> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of ARIN
>> Sent: Wednesday, September 6, 2017 2:36 PM
>> To: arin-ppml@arin.net
>> Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement 
>> for Inter-RIR Transfers
>> 
>> The following has been revised:
>> 
>> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR 
>> Transfers
>> 
>> Revised text is below and can be found at:
>> https://www.arin.net/policy/proposals/2017_4.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-4: Remove Reciprocity Requirement for Inter-RIR 
>> Transfers
>> 
>> Version Date: 6 September 2017
>> 
>> Problem Statement:
>> 
>> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer 
>> proposals. Those RIR communities feel a one-way policy a policy that allows 
>> network operators in their regions to obtain space from another region and 
>> transfer it into AFRINIC and LACNIC may best meet the needs of the operators 
>> in that region.
>> 
>> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated 
>> that ARINs 8.4 policy language will not allow ARIN to participate in such 
>> one-way transfers. The staff formally indicate to AFRINIC that the word 
>> reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to 
>> transfer directly to AFRINIC (in this context).
>> 
>> ARIN as a community should recognize that other RIR operator communities 
>> have different needs than we do. We should recognize that:
>> 
>> - network operators in AFRINIC in LACNIC have need to obtain space in the 
>> market;
>> 
>> - have reasons they think are important to not allow two-way transfers; and
>> 
>> - we should understand that the history of the RIR system has led to LACNIC 
>> and AFRINIC having multiple orders of magnitude less IPv4 address space than 
>> ARIN does.
>> 
>> Policy statement:
>> 
>> Add the following sentence after the first sentence of NRPM 8.4:
>> 
>> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR 
>> transfer policy only when the recipient RIR has an IPv4 total inventory less 
>> than the average (mean) of the IPv4 total inventory among all of the RIRs.
>> 
>> Timetable for implementation: Upon the ratification of any inter-RIR 
>> transfer policy at another RIR that is one-way as described in the problem 
>> statement.
>> ___
>> 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 

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

[Chris Woodfield]

This policy proposal seems, to me, as an attempt to correct a historical 
imbalance in the distribution of IPv4 resources to various RIRs, since the vast 
majority of legacy space - which, to my eyes, it seems that much of the 
transfer supply is originating from - is in the ARIN region.

Given that, this policy only makes sense up to the point that such imbalance 
still exists. If we simply named the target RIRs, we could result in a 
(arguably theoretical) situation where Afrinic and Lacnic wind up transferring 
enough space to push their totals over the average but are still permitted to 
transfer space. if that were to happen, it would require a subsequent policy 
change to keep that imbalance from growing worse.

As such, I support as written and would argue against an approach that targets 
specific RIRs by name.

-C

> On Sep 6, 2017, at 2:10 PM, Cj Aronson  wrote:
> 
> Okay so this formula.. does it just give us Afrinic and Lacnic right?  So why 
> don't we just say that?  Since there are only 5 RIRs it seems that maybe a 
> formula isn't needed?
> 
> 
> {Ô,Ô}
>   (( ))
>   ◊  ◊
> 
> On Wed, Sep 6, 2017 at 12:35 PM, ARIN > 
> wrote:
> The following has been revised:
> 
> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR 
> Transfers
> 
> Revised text is below and can be found at:
> https://www.arin.net/policy/proposals/2017_4.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-4: Remove Reciprocity Requirement for Inter-RIR 
> Transfers
> 
> Version Date: 6 September 2017
> 
> Problem Statement:
> 
> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer 
> proposals. Those RIR communities feel a one-way policy a policy that allows 
> network operators in their regions to obtain space from another region and 
> transfer it into AFRINIC and LACNIC may best meet the needs of the operators 
> in that region.
> 
> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that 
> ARINs 8.4 policy language will not allow ARIN to participate in such one-way 
> transfers. The staff formally indicate to AFRINIC that the word reciprocal in 
> 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly 
> to AFRINIC (in this context).
> 
> ARIN as a community should recognize that other RIR operator communities have 
> different needs than we do. We should recognize that:
> 
> - network operators in AFRINIC in LACNIC have need to obtain space in the 
> market;
> 
> - have reasons they think are important to not allow two-way transfers; and
> 
> - we should understand that the history of the RIR system has led to LACNIC 
> and AFRINIC having multiple orders of magnitude less IPv4 address space than 
> ARIN does.
> 
> Policy statement:
> 
> Add the following sentence after the first sentence of NRPM 8.4:
> 
> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR 
> transfer policy only when the recipient RIR has an IPv4 total inventory less 
> than the average (mean) of the IPv4 total inventory among all of the RIRs.
> 
> Timetable for implementation: Upon the ratification of any inter-RIR transfer 
> policy at another RIR that is one-way as described in the problem statement.
> ___
> 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

Re: [arin-ppml] Draft Policy ARIN-2017-8: Amend the definition of Community Network

[Chris Woodfield]

I’m not aware of at what point in time the Community Networks clause was 
originally added to the NRPM, but I’m betting it was a time where internet 
access was nowhere near as vital a service as it is today. Given that, it’s 
obvious that very few, if any, community networks could operate reliably 
without a certain amount of paid staff.

I would note that IMO the phrase “a large role” could be imprecise; If I were 
writing this policy, I'd choose a term such as “a predominant role” instead - 
still fuzzy, but substantially less so. Alternatively, the policy could require 
organizations to have an all-volunteer board of directors, but that may result 
in some organizations we’d otherwise consider clear beneficiaries of the policy 
being unable to do so (for example, academic networks).

Given the above, I support this policy as written. 

Thanks,

-Chris

> On Aug 22, 2017, at 12:39 PM, ARIN  wrote:
> 
> On 17 August 2017 the ARIN Advisory Council (AC) advanced "ARIN-prop-243: 
> Amend the Definition of Community Network" to Draft Policy status.
> 
> Draft Policy ARIN-2017-8 is below and can be found at:
> https://www.arin.net/policy/proposals/2017_8.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-8: Amend the Definition of Community Network
> 
> Problem Statement:
> 
> The Community Networks section of the NRPM has not been used since 
> implementation in January 2010. Proposal ARIN-2016-7, to increase the number 
> of use cases, was abandoned by the Advisory Council due to lack of feedback. 
> Proposal ARIN 2017-2, to remove all mention of community networks from NRPM 
> was met with opposition by the community. Many responded that the definition 
> of “community network” was too narrow, which could be the reason for lack of 
> uptake.
> 
> Policy statement:
> 
> CURRENT NRPM TEXT:
> 
> “2.11. Community Network
> 
> A community network is any network organized and operated by a volunteer 
> group operating as or under the fiscal support of a nonprofit organization or 
> university for the purpose of providing free or low-cost connectivity to the 
> residents of their local service area. To be treated as a community network 
> under ARIN policy, the applicant must certify to ARIN that the community 
> network staff is 100% volunteers.”
> 
> NEW NRPM TEXT:
> 
> “2.11 Community Network
> 
> A community network is a network organized and operated by a volunteer group, 
> not-for-profit, non-profit, charitable organization, or post-secondary 
> institution for the purpose of providing free or low-cost connectivity to 
> residents in their service area. Critical functions may be handled by paid 
> staff, but volunteers play a large role in offering services available 
> through community networks.”
> 
> 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] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Chris Woodfield]

Agreed. While there are a wide range of opinions on where this line belongs, 
The /47 line appears to have the most consensus, and has my support.

-Chris

> On Aug 15, 2017, at 11:03 AM, David Huberman  wrote:
> 
> Very well done, everyone! Strongly support this draft.
> 
> Kudos to Albert Erdmann and the AC shepherds for their leadership on this 
> proposal.
> 
> 
>> On Aug 15, 2017, at 1:06 PM, ARIN  wrote:
>> 
>> The following has been revised:
>> 
>> * Draft Policy ARIN-2017-5: Equalization of Assignment Registration 
>> requirements between IPv4 and IPv6
>> 
>> Revised text is below and can be found at:
>> https://www.arin.net/policy/proposals/2017_5.html
>> 
>> You are encouraged to discuss all Draft Policies on PPML. The AC will 
>> evaluate the discussion in order to assess the conformance of this draft 
>> policy with ARIN's Principles of Internet number resource policy as stated 
>> in the Policy Development Process (PDP). Specifically, these principles are:
>> 
>> * Enabling Fair and Impartial Number Resource Administration
>> * Technically Sound
>> * Supported by the Community
>> 
>> The PDP can be found at:
>> https://www.arin.net/policy/pdp.html
>> 
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>> 
>> Regards,
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> 
>> 
>> 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 
>> "/64 or more addresses" and change to "/47 or more addresses, or 
>> subdelegation of any size that will be individually announced,"
>> 
>> and
>> 
>> 2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by 
>> deleting the phrase "holding /64 and larger blocks"
>> 
>> and
>> 
>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM 
>> that reads "If the downstream recipient of a netblock ( a /64 or more 
>> addresses) requests publishing in ARIN's registration database, the ISP must 
>> register the netblock, regardless of size."
>> 
>> 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 ad
 m
> inistrative 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 subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).

Re: [arin-ppml] Draft Policy ARIN-2017-7: Retire Obsolete Section 4 From the NRPM

[Chris Woodfield]

You are correct, I was meaning to refer to Section 8. Thanks for pointing out 
the error :)

-C

> On Jul 20, 2017, at 1:01 PM, Owen DeLong <o...@delong.com> wrote:
> 
>> 
>> On Jul 17, 2017, at 12:32 , Chris Woodfield <ch...@semihuman.com 
>> <mailto:ch...@semihuman.com>> wrote:
>> 
>> Hello,
>> 
>> Reviving the thread on Draft Policy ARIN-2017-7. So far, the community 
>> response to the proposal in its current state appears to be universally 
>> negative. 
>> 
>> Having read the comments on this proposal, it could be plausible that an 
>> alternate solution to the problem statement could be that in lieu of 
>> retiring most of the section, specific sections could be substantially 
>> simplified by pointing to the currently-duplicated clauses in Section 6, 
>> eliminating the need to manually keep these sections in sync by applying 
>> similar policy to both where warranted (in particular, the sections around 
>> utilization justification seem like the best candidates).
> 
> I think you mean section 8 as section 6 applies to IPv6 policy and would be 
> absurd if applied to IPv4.
> 
>> Does the community feel that this is a viable route to explore, which would 
>> simplify Section 4 while keeping the necessary relevant sections, in lieu of 
>> the original proposal?
> 
> Perhaps. Or perhaps we just abandon this proposal.
> 
> Owen
> 
>> 
>> Thanks,
>> 
>> -Chris
>> 
>>> On Jun 21, 2017, at 12:16 PM, Austin Murkland <austin.murkl...@qscend.com 
>>> <mailto:austin.murkl...@qscend.com>> wrote:
>>> 
>>> I do not support this policy for the reasons Kevin and Albert outlined.  
>>> This seems a bit premature.
>>> 
>>> Thanks,
>>> 
>>> Austin Murkland
>>> 
>>> On Tue, Jun 20, 2017 at 1:40 PM, ARIN <i...@arin.net 
>>> <mailto:i...@arin.net>> wrote:
>>> On 15 June 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-242: 
>>> Retire Obsolete Section 4 From the NRPM" to Draft Policy status.
>>> 
>>> Draft Policy ARIN-2017-7 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2017_7.html 
>>> <https://www.arin.net/policy/proposals/2017_7.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 <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 
>>> <https://www.arin.net/policy/proposals/index.html>
>>> 
>>> Regards,
>>> 
>>> Sean Hopkins
>>> Policy Analyst
>>> American Registry for Internet Numbers (ARIN)
>>> 
>>> 
>>> 
>>> Draft Policy ARIN-2017-7: Retire Obsolete Section 4 from the NRPM
>>> 
>>> Problem Statement:
>>> 
>>> Since IPv4 free pool exhaustion, policy focus has shifted to transfers. The 
>>> community elected, instead of revamping and modernizing section 4 in light 
>>> of this to, instead, recreate the relevant parts of section 4 in section 
>>> 8.5. As a result, section 4 is generally obsolete and can be mostly 
>>> retired. Since some small amounts of space do occasionally recreate the 
>>> free pool, a mechanism for addressing this must remain and therefore a much 
>>> reduced section 4 is proposed here instead of outright retirement.
>>> 
>>> Policy statement:
>>> 
>>> Replace section 4 of the NRPM with the following:
>>> 
>>> 4. IPv4
>>> 
>>> 4.1 IPv4 Requests
>>> 
>>> 4.1.1 Any new requests for IPv4 addresses allocated or assigned by ARIN 
>>> shall be evaluated based on the criteria for transfer recipients contained 
>>> in section 8.5.
>>> 
>>> 4.1.2 Any approved requests which cannot be met from the ARIN free pool 
>>> shall be handled according to section 4.2.
>>> 
>>> 4.2 Unmet requests
>>> 
>>> In

Re: [arin-ppml] Draft Policy ARIN-2017-7: Retire Obsolete Section 4 From the NRPM

[Chris Woodfield]

Hello,

Reviving the thread on Draft Policy ARIN-2017-7. So far, the community response 
to the proposal in its current state appears to be universally negative. 

Having read the comments on this proposal, it could be plausible that an 
alternate solution to the problem statement could be that in lieu of retiring 
most of the section, specific sections could be substantially simplified by 
pointing to the currently-duplicated clauses in Section 6, eliminating the need 
to manually keep these sections in sync by applying similar policy to both 
where warranted (in particular, the sections around utilization justification 
seem like the best candidates).

Does the community feel that this is a viable route to explore, which would 
simplify Section 4 while keeping the necessary relevant sections, in lieu of 
the original proposal?

Thanks,

-Chris

> On Jun 21, 2017, at 12:16 PM, Austin Murkland  
> wrote:
> 
> I do not support this policy for the reasons Kevin and Albert outlined.  This 
> seems a bit premature.
> 
> Thanks,
> 
> Austin Murkland
> 
> On Tue, Jun 20, 2017 at 1:40 PM, ARIN > 
> wrote:
> On 15 June 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-242: 
> Retire Obsolete Section 4 From the NRPM" to Draft Policy status.
> 
> Draft Policy ARIN-2017-7 is below and can be found at:
> https://www.arin.net/policy/proposals/2017_7.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-7: Retire Obsolete Section 4 from the NRPM
> 
> Problem Statement:
> 
> Since IPv4 free pool exhaustion, policy focus has shifted to transfers. The 
> community elected, instead of revamping and modernizing section 4 in light of 
> this to, instead, recreate the relevant parts of section 4 in section 8.5. As 
> a result, section 4 is generally obsolete and can be mostly retired. Since 
> some small amounts of space do occasionally recreate the free pool, a 
> mechanism for addressing this must remain and therefore a much reduced 
> section 4 is proposed here instead of outright retirement.
> 
> Policy statement:
> 
> Replace section 4 of the NRPM with the following:
> 
> 4. IPv4
> 
> 4.1 IPv4 Requests
> 
> 4.1.1 Any new requests for IPv4 addresses allocated or assigned by ARIN shall 
> be evaluated based on the criteria for transfer recipients contained in 
> section 8.5.
> 
> 4.1.2 Any approved requests which cannot be met from the ARIN free pool shall 
> be handled according to section 4.2.
> 
> 4.2 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.
> 
> Repeated requests are not allowed: an organization may only receive one 
> allocation, assignment, or transfer every 3 months, but 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 cannot be immediately met will also be 
> advised of the availability of the transfer mechanism in section 8.3 as an 
> alternative mechanism to obtain IPv4 addresses.
> 
> 4.2.1. Waiting list
> 
> 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.2.2. Fulfilling unmet needs
> 
> As address blocks become available 

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

[Chris Woodfield]

I’d support the relaxation of SWIP requirements for IPv6 allocations, but 
relaxing SWIP requirements for IPv4 does not, in my view, line up with the 
problem statement as the proposal is written; if the goal is equal treatment, 
then one should align IPv6 policy to existing v4, not change both. I’d 
recommend that we limit this proposal to only the 6.5.5.1 change.

Thanks,

-Chris

> On May 23, 2017, at 7:04 PM, hostmas...@uneedus.com wrote:
> 
> Hello,
> 
> The line has to be drawn somewhere, and the idea when I drafted this proposal 
> was that it was wrong to treat IPv6 less favored than IPv6 as is the current 
> case.  It also bothered me that the average residential and small business 
> account would have to go thru the SWIP process, just because they want to 
> have a minimum or so assignment of IPv6 space for their network, when this 
> was never a requirement for IPv4.  As discussed, a /60 of v6 is much the same 
> as a /32 of v4.
> 
> I chose 16 addresses/networks as the only reasonable number to make the two 
> protocols equal. As already discussed, 1 network is too small.  If the 
> community thinks it is wrong to relax the current IPv4 requirements, I am not 
> opposed to removing 4.2.3.7.1 from the proposal, as long as the community is 
> willing to do something about the "Register every network" problem that is 
> the current policy in v6, and the changes to 6.5.5.1 that I propose.
> 
> While I suggest that a /60 should not trigger registration, if the community 
> would rather kick that up to a /56, I have no problem with this. This would 
> seem to be the more future proof option. Of course such a change calls for a 
> new title, maybe "New policy for IPv6 Assignment Registration", and cite it 
> as allowing even the small networks with a /32 of IPv4 to obtain a reasonable 
> assignment of IPv6 without registration requirements, as is the current case 
> with IPv4.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> On Tue, 23 May 2017, William Herrin wrote:
> 
>> On Tue, May 23, 2017 at 2:35 PM, ARIN  wrote:
>> 
>>> Draft Policy ARIN-2017-5: Equalization of Assignment Registration
>>> requirements between IPv4 and IPv6
>>> 
>>> Policy statement:
>>> 
>>> Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change to
>>> "more than a /28".
>>> 
>> 
>> Hello,
>> 
>> In my opinion...
>> 
>> Leave /29 alone or change it to "more than a single IP address." In these
>> days of IPv4 shortage, substantial networks sit behind small blocks of
>> public addresses. These networks should be documented with reachable POCs
>> lest the anti-spam/virus/malware folks slam down /24 filters for lack of
>> information about how misbehaving networks are partitioned.
>> 
>> 
>>> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to
>>> "more than a /60".
>>> 
>> 
>> Change this to "more than a /56." Service providers should NOT be assigning
>> /64's to end users. If you're doing that, you're doing it wrong. An IPv6
>> customer should be able to have more than one /64 subnet without resorting
>> to NAT so /60 should be the absolute minimum end-user assignment,
>> equivalent for all intents and purposes to an IPv4 /32. If we then want
>> "equivalence" to the /29 policy so that individuals with the minimum and
>> near-minimum assignment do not need to be SWIPed, it makes sense to move
>> the next subnetting level up. In IPv6, assignment is strongly recommended
>> on nibble boundaries, so that means /56.
>> 
>> Regards,
>> Bill Herrin
>> 
>> -- 
>> William Herrin  her...@dirtside.com  b...@herrin.us
>> Dirtside Systems . Web: 
>> 
> ___
> 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-2016-8: Removal of Indirect POC Validation Requirement

[Chris Woodfield]

Is the presence of the phrase “will be sent” in the current policy intended to 
set a requirement for the POC (this email will be sent annually, you must reply 
to it in order to validate the record), or intended as a requirement for ARIN 
staff (ARIN is required to send the email annually)?

To the concept of the random audit approach mentioned earlier, It may be simple 
enough to change “will be sent” to “may be sent”. I’d argue that procedurally 
the sampling rate should be fairly high, however (i.e. no less than, say, 20% 
of records).

-C

> On Jan 5, 2017, at 12:46 PM, Owen DeLong  wrote:
> 
> I oppose the policy as written.
> 
> While I agree that the validation of indirect POCs by ARIN has become a 
> problem, I believe that this is the exact opposite of a good solution.
> 
> Indeed, my organization has a significant problem with vendors creating 
> indirect POC records pointing to individuals within my organization who are 
> not good POCs for the space in question rather than using our existing POC 
> handles which we have provided to those vendors.
> 
> The current POC validation process is one of the few checks and balances 
> which allows us to catch and address these issues.
> 

P.S. Personally, I’d argue that a viable alternate strategy in the absence of 
that check/balance would be to make sure that the requirement to use your 
official POCs is written into your vendor contracts at next renewal, and 
operationally onto a service acceptance checklist backed up by said contract 
language.

> Ideally, we would like to have a way for ARIN to flag and validate new POCs 
> pointed at our organization _BEFORE_ they are actually placed into the 
> database or attached to resources.
> 
> Owen
> 
>> On Dec 20, 2016, at 10:09 , ARIN  wrote:
>> 
>> On 15 December 2016, the ARIN Advisory Council (AC) advanced the following 
>> Proposal to Draft Policy status:
>> 
>> ARIN-prop-233: Removal of Indirect POC Validation Requirement
>> 
>> This Draft Policy has been numbered and titled:
>> 
>> Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement
>> 
>> Draft Policy text is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_8.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)
>> 
>> ##
>> 
>> ARIN-2016-8: Removal of Indirect POC Validation Requirement
>> 
>> Problem Statement:
>> 
>> There are over 600,000 POCs registered in Whois that are only associated 
>> with indirect assignments (reassignments) and indirect allocations 
>> (reallocations). NRPM 3.6 requires ARIN to contact all 600,000+ of these 
>> every year to validate the POC information. This is problematic for a few 
>> reasons:
>> 
>> 1) ARIN does not have a business relationships with these POCs. By 
>> conducting POC validation via email, ARIN is sending Unsolicited Commercial 
>> Emails. Further, because of NRPM 3.6.1, ARIN cannot offer an opt-out 
>> mechanism. Finally, ARIN's resultant listing on anti-spam lists causes 
>> unacceptable damage to ARIN's ability to conduct ordinary business over email
>> 
>> 2) ARIN has previously reported that POC validation to reassignments causes 
>> tremendous work for the staff. It receives many angry phone calls and emails 
>> about the POC validation process. I believe the ARIN staff should be focused 
>> on POC validation efforts for directly issued resources, as that has more 
>> value to internet operations and law enforcement than end-user POC 
>> information.
>> 
>> Policy statement:
>> 
>> Replace the first sentence of 3.6.1:
>> 
>> "During ARIN's annual Whois POC validation, an email will be sent to every 
>> POC in the Whois database."
>> 
>> with
>> 
>> "During ARIN's annual Whois POC validation, an email will be sent to every 
>> POC that is a contact for a direct assignment, direct allocation, 
>> reallocation, and AS number, and their associated OrgIDs."
>> 
>> 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 

Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-4: Transfers for new entrants

[Chris Woodfield]

Support as proposed.

-C

> On Oct 26, 2016, at 2:17 PM, ARIN  wrote:
> 
> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send 
> Recommended Draft Policy ARIN-2016-4: Transfers for new entrants to Last Call:
> 
> The AC provided the following statement to the community:
> 
> This proposal is technically sound and enables fair and impartial number 
> policy. There is support for this policy in the ARIN community as expressed 
> at ARIN 38 and on PPML. There has been no opposition stated to 2016-4. At the 
> ARIN AC meeting held on 10/21/2016, it was agreed that in the "Anything else" 
> section of Recommended Draft Policy 2016-4 stating that 'The text in 4.2.2 
> “for specified transfers, or three months otherwise” and the text in 4.3.3 
> “for specified transfers, or 12 months otherwise” should be stricken if 
> ARIN-prop-227 is adopted' should be followed by ARIN staff as an instruction 
> from the AC, presuming that 2016-2 (which is what ARIN-prop-227 has become) 
> continues to move forward after last call.
> 
> Feedback is encouraged during the Last Call period. All comments should be 
> provided to the Public Policy Mailing List. This Last Call will expire on 9 
> November 2016. 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,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> 
> ARIN-2016-4: Transfers for new entrants
> 
> AC assessment of conformance with the Principles of Internet Number Resource 
> Policy:
> 
> The proposal is technically sound and enables fair and impartial number 
> policy by ensuring that new organizations have a mechanism to access at least 
> a minimum amount of resources from the transfer market. The staff and legal 
> review (as updated 8/19/2016) is non-controversial. There is support and no 
> concerns have been raised by the community regarding the proposal on PPML or 
> elsewhere.
> 
> Problem Statement:
> 
> New organizations without existing IPv4 space may not always be able to 
> qualify for an initial allocation under NRPM 4.2, particularly if they are 
> categorized as ISPs and subject to 4.2.2.1.1. Use of /24. Now that ARIN’s 
> free pool is exhausted, 4.2.1.6. Immediate need states that “These cases are 
> exceptional”, but that is no longer correct. End user organizations requiring 
> less a /24 of address space may also be unable to acquire space from their 
> upstream ISP, and may instead need to receive a /24 from ARIN via transfer.
> 
> Policy statement:
> 
> Replace Section 4.2.2 with:
> 
> 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 
> for specified transfers, or three months otherwise. ISPs renumbering out of 
> their previous address space will be given a reasonable amount of time to do 
> so, and any blocks they are returning will not count against their 
> utilization.
> 
> Replace Section 4.3.2 to read:
> 
> 4.3.2 Minimum assignment
> 
> ARIN’s minimum assignment for end-user organizations is a /24.
> 
> End-user organizations without direct assignments or allocations from ARIN 
> qualify for an initial assignment of ARIN’s minimum assignment size.
> 
> Replace the first two sentences of Section 4.3.3. Utilization rate to read:
> 
> Organizations may qualify for a larger initial allocation by providing 
> appropriate details to verify their 24-month growth projection for specified 
> transfers, or 12 months otherwise.
> 
> Resulting new section 4.3.3 will be:
> 
> Organizations may qualify for a larger initial allocation, by providing 
> appropriate details to verify their 24-month growth projection for specified 
> transfers, or 12 months otherwise.
> 
> The basic criterion that must be met is a 50% utilization rate within one 
> year.
> 
> A greater utilization rate may be required based on individual network 
> requirements.
> 
> Comments:
> 
> Timetable for implementation: Immediate
> 
> Anything else
> 
> The text in 4.2.2 “for specified transfers, or three months otherwise” and 
> the text in 4.3.3 “for specified transfers, or 12 months otherwise” should be 
> stricken if ARIN-prop-227 is adopted.
> ___
> 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] Fraud Policy ?

[Chris Woodfield]

> 
> Yes.  ARIN may do any/all of the above, including “e) revoking 
> number resources obtained fraudulently” with respect to party “B”
> The specific actions are not governed by policy, aside from the 
> references in NRPM section 12.
> 

I’m really curious as to the mechanics of revoking a fraudulent 
allocation/assignment. Do RIRs have any contractual or other legal power to 
stop a prefix from being announced by an ASN (and accepted by upstream 
networks)? Or do we have to just trust providers to filter out an inbound BGP 
advertisement upon notification that it’s fraudulent?

-C

> Thanks,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 
> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@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 for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

[Chris Woodfield]

Reading this thread, as interesting as it has been over the past couple of 
weeks, makes a few things obvious. I make these assertions primarily to allow 
others to point out any glaring misreadings I may be making here.

1. We currently don’t have much info regarding the potential for IPv4 addresses 
to become a speculative commodity. The best we can go by is the experience that 
unregulated markets have the annoying habit of turning just about any type of 
asset into a speculative commodity, whether it be real estate, oil, pork 
bellies, orange juice, or out-of-print Magic: The Gathering cards. Therefore, 
there is a not-unfounded fear among some that should tight needs-based controls 
on IPv4 allocations be lifted, IPv4 space will be speculatively commoditized 
like any other tradable asset.

2. There are community members that don’t think that the above is necessarily a 
bad thing, and others who believe that at least that the nature of IP 
allocations (not being hard assets, like many of the other examples I listed 
above) will curb undesirable speculative activity. 

3. The immediate utilization rule is onerous for many operators and should be 
updated to reflect current practices.

As such, here’s my thoughts on this:

1. There seems to be a wide gulf between those advocating keeping the 30-day 
rule and those advocating removing it entirely, which does remove what I do 
feel to be an effective enforcement policy (when followed up on, of course) 
against allocating space that does not get used. That said, I haven’t seen any 
conversations around relaxing the rule to make it less onerous, which could be 
a viable middle ground here. For example, we could change “immediate” to 
“within 60 (or 90) days"; or we could allow the definition of “immediate usage” 
to incorporate something like “must be announcing the prefix to a peer”. (if 
there was such a discussion, I’m not finding it in the PPML archives, so please 
help me find one if it exists).

2. Remember that ARIN has regular meetings, and a policy development process 
for a reason: So that operational issues with existing policy can be modified 
as needed to suit the needs of the community and to better execute on RIR 
principles and goals. If this, or any proposal, is adopted and we do see the 
negative effects that some are warning against…we have the power to roll it 
back! And I’d expect that if we were to see rampant speculation/monetization of 
IPv4 space as a result of this change, ARIN should do exactly that.

As such, I’ll state my position on the policy as currently undecided. I’d be in 
strong support of a policy that incorporates items #1 and with the community’s 
commitment to #2.

Thanks,

-Chris

> On May 19, 2016, at 8:48 PM, Owen DeLong  wrote:
> 
> 
>> On May 19, 2016, at 07:41 , Mueller, Milton L > > wrote:
>> 
>>  
>>   <>
>> From: Owen DeLong [mailto:o...@delong.com ] 
>> 
>>  
>> Transfers are not rationed by price…
>>  
>> MM: False. This is like saying white is black. Transfers involve a payment 
>> by the receiving party. They are, therefore, rationed by price. Not much 
>> room for debate here. You’re just wrong. 
> 
> Rationed: a fixed allowance of provisions or food, especially for soldiers or 
> sailors or for civilians during a shortage: a daily ration of meat and bread. 
> 2. an allotted amount: They finally saved up enough gas rations for the trip.
> 
> I simply do not agree with you that price constitutes any sort of limitation 
> on the amount of resources that can be acquired by an organization with 
> sufficiently deep pockets.
> 
> Therefore, you are simply wrong.
> 
>> Price does not ensure that the purchaser has actual need for the resources, 
>> it merely insures that they have monetary resources that they are willing to 
>> trade for number resources.
>>  
>> MM: It means that they value the resources and thus have some kind of need 
>> for them. There are 1,000 other things they could spend that money on but 
>> the buyer has determined that the value they will get out of the numbers is 
>> at least equal to the value of the money they spend.
> 
> It means that they believe the resources have value. That is different from 
> having need for them or from valuing them. This is the sophistry in which you 
> consistently engage hoping nobody will notice the inaccuracy in your 
> statement.
> 
> For example, I may perceive that a stock has value or will have a greater 
> value in the future. I may purchase the stock on that basis. It does not mean 
> that I value the particular stock or the company it represents. It further 
> does not mean that I have any need whatsoever for the stock other than my 
> hope that its value will increase and that I can sell it at a gain.
> 
>> You’ve presented no evidence whatsoever to support your conclusion that 
>> stringent needs assessment raises the price
>>  
>> In fact, in the RIPE 

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

[Chris Woodfield]

Agreed that we can park this for now, provided we can come up with a measurable 
turning point (let’s say, where the trend points to 1-2 years from exhaustion) 
where we should revive the discussion.

-C

> On Apr 8, 2016, at 1:39 PM, Brian Jones  wrote:
> 
> I believe the current practice is sufficient for now. If a sudden run on 
> 2-byte ASN's occurs this issue should be resurrected at that time. 
> 
> --
> Brian​ E Jones​
> 
> --
> Brian
> 
> On Fri, Apr 8, 2016 at 12:06 PM, Andrew Dul  > wrote:
> Do other members of the ARIN community believe that the current policy and 
> operational practice is sufficient for now, or are there policy changes 
> needed at this time?
> 
> Thanks,
> Andrew
> 
> On 4/7/2016 12:24 PM, Scott Leibrand wrote:
>> Thanks, John.
>> 
>> It sounds to me like ARIN is already doing the right thing (saving 2-byte 
>> ASNs for people who specifically want them), and that is sufficient for the 
>> time being.  It does not appear that additional restrictions on who may 
>> request a 2-byte ASN are necessary at this time.  If at some point 5+ years 
>> down the road the rate of 2-byte ASN demand starts to exceed the recovered 
>> supply and the 2-byte ASN inventory is depleted, we can consider a waiting 
>> list and/or technical requirements for requesting a 2-byte ASN at that time.
>> 
>> Is there any other reason we need to consider taking action sooner?  Was 
>> there something else I'm missing that prompted ARIN staff to start the 
>> consultation process around a 2-byte ASN waiting list?
>> 
>> -Scott
>> 
>> On Thu, Apr 7, 2016 at 11:44 AM, John Curran > > wrote:
>> Folks -
>> 
>> Please forgive this omnibus email of information, but we've had sufficient 
>> individual
>> questions for 2-byte ASN data that it simply made more sense to provide one 
>> full
>> summary rather than reply to each question individually...
>> 
>> ARIN continues to have classic, 2-byte, AS numbers in inventory. Over the 
>> last few
>> years, we have received small blocks of them in our new delegations from the 
>> IANA,
>> obtained them from customer returns of AS numbers, or through revocations of 
>> AS
>> numbers due to non-payment of registration fees.
>> 
>> Our last AS block delegation from IANA was on 29 April 2015.  We received 99 
>> 2-byte
>> ASNs and 925 4-byte ASNs at that time, and do not expect to receive any 
>> additional
>> 2-byte ASNs from the IANA in future delegations.  The 2-byte ASNs received 
>> from the
>> IANA in 2015 were added to the inventory and placed on hold.  The reason 
>> that the
>> 2-byte ASNs were put on hold is that was not responsible to issue from the 
>> dwindling
>> quantity of these resources to parties that did not specifically request 
>> such while we
>> were still receiving AS number requests specifically asking for 2-byte AS 
>> numbers.
>> 
>> As of today, we currently have the following 2-byte ASNs in ARIN inventory:
>> 
>>387 2-byte AS numbers on hold (most were routed at some point)
>>535 2-byte AS numbers revoked
>>133 2-byte AS numbers returned
>> 
>>   = 1,055 2-byte AS numbers returned/revoked/held (Total)
>> 
>> Customers requesting ASNs receive a 4-byte ASN by default.  If a request 
>> comes in
>> that specifically requests a 2-byte ASN, we inform the customer that we have 
>> noted
>> their special request and that we will accommodate it at the issuance phase 
>> of the
>> ticket process if we have 2-byte ASN available at that time.
>> 
>> Rate of issuance for 2-byte ASNs per month -
>> 
>> 1/2015: 68
>> 2/2015: 77
>> 3/2015: 74
>> 4/2015: 60
>> 5/2015: 7
>> 6/2015: 12
>> 7/2015: 16
>> 8/2015: 4
>> 9/2015: 7
>> 10/2015: 11
>> 11/2015: 7
>> 12/2015: 11
>> 1/2016: 5
>> 2/2016: 6
>> 3/2016: 13
>> 
>> A waiting list will only be applicable after depletion of the present 2-byte 
>> ASN inventory,
>> hence the following general run-out estimates are provided for consideration:
>> 
>>- If we release all of the 2-byte ASNs from hold and issue ASNs strictly 
>> from smallest
>>  to largest, i.e. the practice prior to May 2015, it is likely that the 
>> current inventory of
>>  2-byte ASN’s would last somewhere between 6 to 12 months.
>> 
>>   -  If we continue the current approach (wherein 4-byte ASNs are issued by 
>> default and
>>  2-byte ASNs are only issued upon special request), the current 
>> inventory of 2-byte
>>  ASNs would appear to last for many years (5+ years at present rate).
>> 
>> I hope the above information helps in your policy development efforts!
>> 
>> Thank you,
>> /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