Re: [arin-ppml] (Corrected copy) Recommended Draft Policy ARIN-2023-4: Modernization of Registration Requirements

[Andrew Dul via ARIN-PPML]

I do not support this Draft Policy at this time, as I noted earlier...

   If we are "modernizing" the language of this section that should
   include removing old and outdated terminology.  While the terms
   "WHOIS" and "SWIP" are popular in the community, they are protocols
   and methods which are being replaced by new modern protocols and
   methods.  The language should be updated to reflect those new terms
   or use generic terms such as directory services or registration records.


Thanks,
Andrew


On 3/6/2024 12:06 PM, ARIN wrote:

Corrected copy with Statement of Conformance Included.

* ARIN-2023-4: Modernization of Registration Requirements

The text of the Recommended Draft Policy is below, and may also be found at:

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


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,

Eddie Diego
Policy Analyst
American Registry for Internet Numbers (ARIN)


Recommended Draft Policy ARIN-2023-4: Modernization of Registration Requirements

Current Text (21 September 2023)

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

Draft Policy ARIN-2023-4: Modernization of Registration Requirements, conforms 
to the principles of the ARIN Policy Development Process. This draft policy is 
found to be fair, impartial and technically sound. Based on community feedback 
and AC discussion we motion to move ARIN-2023-4: Modernization of Registration 
Requirements to Recommended Draft. If adopted this policy aims to modernize the 
registration related policies in Section 4.

Problem Statement:

Registration is central to the value provided by ARIN to the
community. Registry quality depends greatly upon the timely
registration of reassignments from ISPs to end users. The motivation
for registration has waned since the depletion of the free pool. At
the same time, privacy laws have been introduced in many jurisdictions
across ARIN’s service region which constrain registration in certain
cases. This combination of forces has generally discouraged many ISPs
from registering reassignments. Registration remains vital to a number
of stakeholders, including law enforcement and network operators.

This proposal aims to modernize the registration-related policies in
Section 4 by introducing language that is meant to make registration
requirements more adaptable to changing privacy laws, while reminding
ISPs of the importance of registration when feasible for the benefit
of the community.

Policy Statement:

In section 4.2.3.7.1,
Replace
"Each IPv4 reassignment or reallocation containing a /29 or more
addresses shall be registered via SWIP or a directory services system
which meets the standards set forth in section 3.2."
With
"Each IPv4 reassignment or reallocation containing a /29 or more
addresses shall be registered in the WHOIS directory via SWIP, or a
directory services system which meets the standards set forth in
section 3.2, within 14 days."

Retire section 4.2.3.7.2 Reassignments and Reallocations Visible
Within Seven Days

Rename 6.5.5.1
From
"Reassignment Information"
To
"Reassignment and Reallocation Information"

In section 6.5.5.1,
Replace
"Each static IPv6 reassignment or reallocation containing a /47 or
more addresses, or subdelegation of any size that will be individually
announced, shall be registered in the WHOIS directory via SWIP or a
distributed service which meets the standards set forth in section
3.2. Reassignment and reallocation registrations shall include each
client’s organizational information, except where specifically
exempted by this policy."
With
"Each static IPv6 reassignment or reallocation containing a /47 or
more addresses, or subdelegation of any size that will be individually
announced, shall be registered in the WHOIS directory via SWIP, or a
distributed service which meets the standards set forth in section
3.2, within 14 days. Reassignment and reallocation registrations shall
include each client’s organizational information, except where
specifically exempted by this policy."

Retire section 6.5.5.2 Reassignments and Reallocations Visible Within Seven Days

Timetable for Implementation: 90 days.






___
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 contacti...@arin.net  if you experience any issues.


___
ARIN-PPML
You are receiving 

Re: [arin-ppml] Revised - Draft Policy 2023-4: Modernization of Registration Requirements

[Andrew Dul]

If we are "modernizing" the language of this section that should include 
removing old and outdated terminology.  While the terms "WHOIS" and 
"SWIP" are popular in the community, they are protocols and methods 
which are being replaced by new modern protocols and methods.  The 
language should be updated to reflect those new terms or use generic 
terms such as directory services or registration records.


Thanks,

Andrew

On 1/17/24 1:16 PM, ARIN wrote:


Problem Statement:

Registration is central to the value provided by ARIN to the

community. Registry quality depends greatly upon the timely

registration of reassignments from ISPs to end users. The motivation

for registration has waned since the depletion of the free pool. At

the same time, privacy laws have been introduced in many jurisdictions

across ARIN’s service region which constrain registration in certain

cases. This combination of forces has generally discouraged many ISPs

from registering reassignments. Registration remains vital to a number

of stakeholders, including law enforcement and network operators.

This proposal aims to modernize the registration-related policies in

Section 4 by introducing language that is meant to make registration

requirements more adaptable to changing privacy laws, while reminding

ISPs of the importance of registration when feasible for the benefit

of the community.

Policy Statement:

In section 4.2.3.7.1,

Replace

"Each IPv4 reassignment or reallocation containing a /29 or more

addresses shall be registered via SWIP or a directory services system

which meets the standards set forth in section 3.2."

With

"Each IPv4 reassignment or reallocation containing a /29 or more

addresses shall be registered in the WHOIS directory via SWIP, or a

directory services system which meets the standards set forth in

section 3.2, within 14 days."

Retire section 4.2.3.7.2 Reassignments and Reallocations Visible

Within Seven Days

Rename 6.5.5.1

From

"Reassignment Information"

To

"Reassignment and Reallocation Information"

In section 6.5.5.1,

Replace

"Each static IPv6 reassignment or reallocation containing a /47 or

more addresses, or subdelegation of any size that will be individually

announced, shall be registered in the WHOIS directory via SWIP or a

distributed service which meets the standards set forth in section

3.2. Reassignment and reallocation registrations shall include each

client’s organizational information, except where specifically

exempted by this policy."

With

"Each static IPv6 reassignment or reallocation containing a /47 or

more addresses, or subdelegation of any size that will be individually

announced, shall be registered in the WHOIS directory via SWIP, or a

distributed service which meets the standards set forth in section

3.2, within 14 days. Reassignment and reallocation registrations shall

include each client’s organizational information, except where

specifically exempted by this policy."

Retire section 6.5.5.2 Reassignments and Reallocations Visible Within 
Seven Days


Timetable for Implementation: 90 days.


___
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 contacti...@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] Should we disallow an AC member from submitting a policy proposal?

[Andrew Dul]

On 10/27/2023 1:24 PM, John Curran wrote:



On Oct 27, 2023, at 2:01 PM, William Herrin  wrote:

On Thu, Oct 26, 2023 at 9:28 AM Andrew Dul  wrote:

Should we disallow an AC member from submitting a policy proposal?

Hi Andrew,

You got me thinking about this. There might be a useful change to the
process here. Not disallowed, but: before an AC member can introduce a
policy proposal, require them to post the problem statement (without a
policy proposal) to the PPML and solicit feedback for, say, two weeks.
Make that the only hard restriction on an AC member proposing policy
that is not faced by the general public.

What do you think?


Bill,

Its a reasonable restriction from my perspective and also one that 
likely brings policies on to the public mailing list sooner.   Which 
could be a benefit.  If you feel its worth considering after this 
discussion please put it in via the ACSP process as that is the formal 
method now for changes to the PDP to be considered for future revisions.


https://www.arin.net/participate/community/acsp/process/


Thanks,

Andrew



As an relevant side-note, I will observe that there was discussion during the 
PDP update
of requiring that _all_ policy proposals initially start solely as a problem 
statement, and
only after that problem statement had been discussed by the community would work
on actual policy proposal text commence.

That approach was deemed too restrictive, as sometime as a change to policy 
text is so
straightforward that there was no reason to deprive the community of clear 
policy change
text upfront.  I do not know know if the same is the case for your proposed 
hobbling of the
ARIN AC members, but provide it as related background.

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] AC candidates

[Andrew Dul]

On 10/26/2023 9:20 AM, William Herrin wrote:

On Thu, Oct 26, 2023 at 8:27 AM Andrew Dul  wrote:

While the PPML is open to any participant we see very few active
collaborators on this list.  My perception as someone who has been on
this list for a long time is that the number of active collaborators has
decreased over time.

Hi Andrew,

It plummeted after the Board changed the AC's role from shepherding
policy proposals to developing policy proposals.


From a policy development perspective the AC's role has not changed 
significantly in more than a decade.  The AC's official role is still 
being policy shepherds.


When an AC member submits a policy proposal they do it as a member of 
the community not in their capacity as AC members.


I realize that might be a distinction with out a difference, but I 
wanted to point it out.


Should we disallow an AC member from submitting a policy proposal?

Andrew




IMO, one of the worst decisions the board has made. Why should any
member of the general public make the effort to craft a proposal when
it's going to be committeed to death before it can come to a consensus
call?

Regards,
Bill Herrin





___
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] AC candidates

[Andrew Dul]

On 10/26/2023 12:42 AM, William Herrin wrote:

Howdy,

As I think about how to vote for the AC candidates, I figured I'd
check the list archives to see how each one went about arguing for and
against proposals over the years. Seems like a reasonable way to
evaluate a candidate judged "well qualified," right?

Imagine my surprise. Of the 14 candidates, only 5  have posted here as
a member of the general public. Ever. Even a couple of the current AC
members have only posted here in their official capacity on the AC.

I don't know what to say.I just don't know what to say.


Bill,

I have also used this metric in the past when considering AC 
candidates.  We will have a large turnover in AC seats this year so 
perhaps this metric is a bit skewed this year?   Or maybe it is a trend?


I think one question to ask would be is this an artifact of the AC 
candidates and current AC members and PPML or PPML as a whole? I 
certainly would like to see more collaboration on the PPML by AC members 
but we just don't see that.  There has been discussion on and off about 
how the AC contributes to the public discussion with an awareness of 
their position could create a bias in the discussion.  This has been 
specifically discussed regarding comments at the microphone during the 
public policy meeting, but the sentiment I think also carries over a 
little bit onto the list.


While the PPML is open to any participant we see very few active 
collaborators on this list.  My perception as someone who has been on 
this list for a long time is that the number of active collaborators has 
decreased over time.  One could certainly "do the research" to confirm 
or deny that perception.  There could be many reasons for that, but are 
those reasons also applicable to AC members and candidates?



Hope this helps,

Andrew  (AC member but not speaking for the AC)


___
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

[Andrew Dul]

In 4.4 it does say “ARIN will make a list of these blocks publicly 
available.” Is that information available with the IXP name etc? 

I believe this is the list that ARIN is currently publishing.

https://www.arin.net/reference/research/statistics/microallocations/#micro-allocations-for-exchange-points

I was going to say it probably would be helpful if there was a machine 
readable format for this...but looks like someone already thought of that...


https://www.arin.net/participate/community/acsp/suggestions/2019/2019-24/

Andrew

On 6/29/2023 8:42 AM, Kevin Blumberg wrote:


I don’t support this policy.

I’ll echo what other operators have said, renumbering is non-trivial 
at an IXP.


Is ARIN even able to provide reverse DNS delegation for a /26 at this 
point?


The CI pool is in my mind working as intended, the drawn down from the 
pool as shown earlier has been reasonable.


If the definition of who is an IXP for the purposes of getting space, 
that is an entirely different proposal and problem statement. In 4.4 
it does say “ARIN will make a list of these blocks publicly 
available.” Is that information available with the IXP name etc?


Thanks,

Kevin Blumberg

*From:*ARIN-PPML  *On Behalf Of *Matt Peterson
*Sent:* Wednesday, June 21, 2023 4:19 AM
*To:* arin-ppml@arin.net
*Subject:* Re: [arin-ppml] Draft Policy ARIN-2023-2: /26 initial IPv4 
allocation for IXPs


It's clear this proposal did not receive feedback from those of us 
who operate IXP's /(or those who lived through the ep.net 
 era)./ Renumbering events are often multi-year efforts 
for an IXP, this "savings" is not worth the operational overhead. I'm 
not in support of this proposal. This is a solution looking for a 
problem, we have both the appropriate pool size and a method to refill.


If anything, the 4.4 requirement language around /"other participants 
(minimum of three total)" /could use some attention. ARIN's service 
region has many "shadow IXP's", which may have 3 unique ASN's /(say a 
route server, route collector, and management network) /- but are all 
operated by the same organization. That does not seem like a 
legitimate definition of an exchange point, especially when that 
operator is the only participant over several years.


--Matt

On Tue, Jun 20, 2023 at 8:54 AM 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


___
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 contacti...@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

[Andrew Dul]

Indeed, we therefore have to define priorities of allocations for the 
depleted IPv4 pool.


I wanted to point out that if the community believed that sticking with 
the /24 allocations is best for IXPs then it appears we have sufficient 
resources to do so into the future.  At the present time the policy 
states that IXP (4.4) allocations have a higher priority than a generic 
wait-list request.  The community created this priority believing that 
IXPs are critical infrastructure that require these resources.


Andrew

On 6/20/2023 10:53 AM, Chris Woodfield wrote:
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 



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  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 f

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

[Andrew Dul]

Leasing is not currently defined in the NRPM.  Perhaps we should define 
behavior that we wish to restrict in terms that are already defined or 
are less ambiguous in this community.


Perhaps replace the words "for lease" with "reassignment to another 
organization without direct network services"


Andrew

On 6/20/2023 9:28 AM, Scott Leibrand wrote:
Is leasing defined anywhere in the NRPM? How would this be enforced? 
Is the intent to disallow all reassignments? To get ARIN into the 
business of inspecting customer contracts and network configs to see 
if there is a bona fide connectivity relationship vs. a fig-leaf one? 
Something else?


Scott


On Jun 20, 2023, at 8:54 AM, ARIN  wrote:



On 15 June 2023, the ARIN Advisory Council (AC) accepted 
“ARIN-prop-321: Amendment of the waitlist agreement to include a 
restriction on leasing” as a Draft Policy.


Draft Policy ARIN-2023-3 is below and can be found at:

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

You are encouraged to discuss all Draft Policies on PPML. The AC will 
evaluate the discussion to assess the conformance of this draft 
policy with ARIN's Principles of Internet number resource policy as 
stated in the Policy Development Process (PDP). Specifically, these 
principles are:


* Enabling Fair and Impartial Number Resource Administration

* Technically Sound

* Supported by the Community

The PDP can be found at:

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

Draft Policies and Proposals under discussion can be found at: 
https://www.arin.net/participate/policy/drafts/


Regards,

Eddie Diego

Policy Analyst

American Registry for Internet Numbers (ARIN)

Draft Policy ARIN-2023-3: Amendment of the waitlist agreement to 
include a restriction on leasing


Problem Statement:

Currently section 4.18 prohibits the transfer of waitlist space for a 
period of 60 months. However, there are no restrictions on leasing 
out the space immediately after obtaining it from the waitlist.


Policy statement:

Modify the current text in 4.18 from:

ARIN will only issue future IPv4 assignments/allocations (excluding 
4.4 and 4.10 space) from the ARIN Waitlist. The maximum size 
aggregate that an organization may qualify for at any one time is a 
/22. Organizations will be able to elect a smaller block size than 
they qualify for down to a /24. Organizations which hold more than a 
/20 equivalent of IPv4 space in aggregate (exclusive of special use 
space received under section 4.4 or 4.10) are not eligible to apply. 
Address space distributed from the waitlist will not be eligible for 
transfer, with the exception of Section 8.2 transfers, for a period 
of 60 months. This policy will be applied to all future distributions 
from the waitlist to include those currently listed.


to

ARIN will only issue future IPv4 assignments/allocations (excluding 
4.4 and 4.10 space) from the ARIN Waitlist. The maximum size 
aggregate that an organization may qualify for at any one time is a 
/22. Organizations will be able to elect a smaller block size than 
they qualify for down to a /24. Organizations which hold more than a 
/20 equivalent of IPv4 space in aggregate (exclusive of special use 
space received under section 4.4 or 4.10) are not eligible to apply. 
Address space distributed from the waitlist will not be eligible for 
lease or transfer, with the exception of Section 8.2 transfers, for a 
period of 60 months. This policy will be applied to all future 
distributions from the waitlist to include those currently listed.


Comments: None

Timetable for implementation: Immediate

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


___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contacti...@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

[Andrew Dul]

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 



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

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

[Andrew Dul]

On 11/17/22 10:13 AM, ARIN wrote:


Draft Policy ARIN-2022-13: Clean-up of NRPM Section 2.10

Problem Statement:

As a result of ARIN’s fee harmonization direct assignments are no 
longer being utilized within ARIN databases therefore language around 
that has been deprecated and should be modernized.


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 Site is the smallest subnet in a network 
requiring IPv6 address space.”



I still do not believe that this new definition is any clearer than the 
old definition, and in someways I think it is less clear.  Is every 
device that needs/64 an endsite?  Which means every device then needs a 
/48 or /56?


Thanks,

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

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

[Andrew Dul]

Updated markup and new version can be found here for your review.

https://www.arin.net/participate/policy/drafts/pdf/NRPM-Section11-update-20221021.pdf
https://www.arin.net/participate/policy/drafts/pdf/NRPM-Section11-update-20221021-clean.pdf 



Thanks,
Andrew

On 10/26/22 10:44 AM, ARIN wrote:


The following Draft Policy has been revised:

* ARIN-2022-8: Streamlining Section 11 Policy Language

Revised text is below and can be found at:

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

You are encouraged to discuss all Draft Policies on PPML. The AC will 
evaluate the discussion to assess the conformance of this Draft Policy 
with ARIN's Principles of Internet number resource policy as stated in 
the Policy Development Process (PDP). Specifically, these principles are:


* Enabling Fair and Impartial Number Resource Administration

* Technically Sound

* Supported by the Community

The PDP can be found at:

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

Draft Policies and Proposals under discussion can be found at:

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

Regards,

Sean Hopkins

Senior Policy Analyst

American Registry for Internet Numbers (ARIN)

Draft Policy ARIN-2022-8: Streamlining Section 11 Policy Language

Problem Statement:

Section 11 of the NRPM contains a great deal of language that is 
either explicitly not policy, or is not impactful on ARIN's 
administration of Internet number resources for experimental 
allocations, or to the customers requesting said resources. A revision 
to transform Section 11 into a collection of policies for experimental 
allocations serves to make the Section more easily digested by the 
reader, and a more functional reference for customers and ARIN staff 
during experimental allocation requests.


Policy Statement:

Section 11 Overview

Current text:

11. Experimental Internet Resource Allocations

ARIN will allocate Numbering Resources to entities requiring temporary 
Numbering Resources for a fixed period of time under the terms of 
recognized experimental activity.


"Numbering Resources" refers to unicast IPv4 or IPv6 address space and 
Autonomous System numbers.

The following are the criteria for this policy:

Proposed text:

11. Experimental Internet Resource Allocations

ARIN will allocate Number Resources to organizations requiring 
temporary Number Resources for a fixed period of time under the terms 
of a recognized experimental activity.


Section 11.1

Current text:

11.1. Documentation of Recognized Experimental Activity

A Recognized Experimental Activity is one where the experiment's 
objectives and practices are described in a publicly accessible 
document. It is a normal requirement that a Recognized Experimental 
Activity also includes the undertaking that the experiment's outcomes 
be published in a publicly accessible document at the end of the 
experiment. The conditions for determining the end of the experiment 
are to be included in the document. Applicants for an experimental 
allocation are expected to demonstrate an understanding that when the 
experiment ends, the allocation will be returned; a successful 
experiment may need a new allocation under normal policies in order to 
continue in production or commercial use, but will not retain the 
experimental allocation.


A "publicly accessible document" is a document that is publicly and 
openly available free of charges and free of any constraints of 
disclosure.


ARIN will not recognize an experimental activity under this policy if 
the entire research experiment cannot be publicly disclosed.


ARIN has a strong preference for the recognition of experimental 
activity documentation in the form of a document which has been 
approved for publication by the IESG or by a similar mechanism as 
implemented by the IETF.


Proposed text:

11.1. Eligibility Criteria for Recognized Experimental Activity

The eligibility criteria for a recognized experimental activity under 
this policy are:


The experiment’s description and objectives are published in a 
publicly accessible document, which for the purpose of this policy 
means that the document is readily available free of charges to the 
public, and free of any constraints of disclosure within one year 
after the end of the experiment;


The experiment’s outcomes must also be published in a publicly 
accessible document;


* Demonstration to ARIN that the experimental activity is technically 
sound within the meaning of ARIN’s Policy Development Process;


* Demonstration to ARIN that the experimental activity is technically 
coordinated in that consideration of any potential negative impact of 
the proposed experiment on the operation of the Internet and its 
deployed services has been considered, and a description of 
experimenter mitigation plans to contain any negative impacts has been 
provided.


Retire Sections 11.2 and 11.3

Section 11.4

Current text:

11.4. Resource Allocation Term and Renewal

The Numbering 

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

[Andrew Dul]

This is a typo in the latest draft the shepherds intend to change the 
word "policy" to "document" for this bullet.


Andrew

On 10/18/22 3:02 PM, John Santos wrote:
"Policy" is completely the wrong word.  Policies must be enacted 
according the the Policy Development Process, not by the published 
results of an experiment, as interpreted by the experimenter.


I agree that the results of any experiment conducted under this policy 
should be publicly and freely available.  Perhaps ARIN should provide 
a page or set of pages on their web site with the description, status 
and results of all past and current experiments conducted under this 
policy, but I think that is an operational issue.  The policy itself 
should just say something like "the results of any experiments 
conducted under this policy must be made publicly and freely 
available" and leave the details to the ARIN staff.


On 10/18/2022 5:07 PM, Martin Hannigan wrote:


+1 Our policy should merely enable the ability to do experiments, not 
drive their outcomes one way or the other.


On Tue, Oct 18, 2022 at 11:39 AM A N > wrote:


    Agree with Owen - "policy" is not the optimal word. "The 
experiment’s

    outcomes must also be published in a publicly accessible policy”.
    Most of the time, the results of an experiment don't end up in a 
policy.
    They end up in a research paper, or end up being used by a 
company/lab. I

    think the spirit of this sentence is that doing an experiment on
    ARIN-allocated temp research space should result in publishing 
(however

    that's done - could even be a blog post or something) these results
    publicly. Perhaps a better phrasing is publicly accessible document,
    repository or format?

    Anita Nikolich
    (wearing non-ARIN AC hat)

    On Sat, Oct 15, 2022 at 6:02 PM Owen DeLong via ARIN-PPML
    mailto:arin-ppml@arin.net>> wrote:

    “The experiment’s outcomes must also be published in a publicly
    accessible policy”—
    I don’t think policy is the correct final word to this 
sentence… Many
    experiments (most I would venture to say) don’t result in 
policies.
    Perhaps document, report, or some other word would be more 
appropriate here?


    "Demonstration to ARIN that the experimental activity is 
technically
    coordinated in that consideration of any potential negative 
impact of

    the proposed experiment on the operation of the Internet and its
    deployed services has been considered, and a description of 
experimenter
    mitigation plans to contain any negative impacts has been 
provided.” —
    I think “adequately coordinated”, “properly coordinated”, or 
simply

    “coordinated” would be better choices of wording here.

    I think 11.4 can be further simplified… suggest:
    The number Resources are allocated for the duration of the 
experiment,
    not to exceed one year. An extension may be granted at staff 
discretion
    upon application to ARIN documenting the need for more time 
to complete

    a successful experiment.

    Owen



    On Sep 19, 2022, at 13:49 , ARIN mailto:i...@arin.net>> wrote:

    The following Draft Policy has been revised:
    __ __
    * ARIN-2022-8: Streamlining Section 11 Policy Language
    __ __
    Revised text is below and can be found at:
    __ __
    https://www.arin.net/participate/policy/drafts/2022_8/

    __ __
    You are encouraged to discuss all Draft Policies on PPML. 
The AC will
    evaluate the discussion to assess the conformance of this 
Draft Policy
    with ARIN's Principles of Internet number resource policy as 
stated in
    the Policy Development Process (PDP). Specifically, these 
principles are:

    __ __
    * Enabling Fair and Impartial Number Resource Administration
    * Technically Sound
    * Supported by the Community
    __ __
    The PDP can be found at:
    https://www.arin.net/participate/policy/pdp/
    
    __ __
    Draft Policies and Proposals under discussion can be found at:
    https://www.arin.net/participate/policy/drafts/

    __ __
    Regards,
    __ __
    Sean Hopkins
    Senior Policy Analyst
    American Registry for Internet Numbers (ARIN)
    __ __
    __ __
    __ __
    Draft Policy ARIN-2022-8: Streamlining Section 11 Policy 
Language

    __ __
    Problem Statement:
    __ __
    Section 11 of the NRPM contains a great deal of language 
that is

    either explicitly not policy, or is not impactful on ARIN's
    administration of Internet number resources for experimental
    allocations, or to the customers requesting said resources. 
A revision
 

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

[Andrew Dul]

Hello,

We have prepared an updated documents showing the intended changes of 
section 11 to assist with the discussion at the upcoming meeting.   
Please see the links below or the attached PDFs.


https://www.arin.net/participate/policy/drafts/pdf/NRPM-Section11-update-20221012.pdf

https://www.arin.net/participate/policy/drafts/pdf/NRPM-Section11-update-20221012-clean.pdf


Thank you,
Andrew


On 9/19/2022 1:49 PM, ARIN wrote:


The following Draft Policy has been revised:

* ARIN-2022-8: Streamlining Section 11 Policy Language

Revised text is below and can be found at:

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

You are encouraged to discuss all Draft Policies on PPML. The AC will 
evaluate the discussion to assess the conformance of this Draft Policy 
with ARIN's Principles of Internet number resource policy as stated in 
the Policy Development Process (PDP). Specifically, these principles are:


* Enabling Fair and Impartial Number Resource Administration

* Technically Sound

* Supported by the Community

The PDP can be found at:

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

Draft Policies and Proposals under discussion can be found at:

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

Regards,

Sean Hopkins

Senior Policy Analyst

American Registry for Internet Numbers (ARIN)

Draft Policy ARIN-2022-8: Streamlining Section 11 Policy Language

Problem Statement:

Section 11 of the NRPM contains a great deal of language that is 
either explicitly not policy, or is not impactful on ARIN's 
administration of Internet number resources for experimental 
allocations, or to the customers requesting said resources. A revision 
to transform Section 11 into a collection of policies for experimental 
allocations serves to make the Section more easily digested by the 
reader, and a more functional reference for customers and ARIN staff 
during experimental allocation requests.


Policy statement:

Section 11 Overview

Current text:

11. Experimental Internet Resource Allocations

ARIN will allocate Numbering Resources to entities requiring temporary 
Numbering Resources for a fixed period of time under the terms of 
recognized experimental activity.


"Numbering Resources" refers to unicast IPv4 or IPv6 address space and 
Autonomous System numbers.

The following are the criteria for this policy:

Proposed text:

11. Experimental Internet Resource Allocations

ARIN will allocate Number Resources to organizations requiring 
temporary Number Resources for a fixed period of time under the terms 
of a recognized experimental activity.


Section 11.1

Current text:

11.1. Documentation of Recognized Experimental Activity

A Recognized Experimental Activity is one where the experiment's 
objectives and practices are described in a publicly accessible 
document. It is a normal requirement that a Recognized Experimental 
Activity also includes the undertaking that the experiment's outcomes 
be published in a publicly accessible document at the end of the 
experiment. The conditions for determining the end of the experiment 
are to be included in the document. Applicants for an experimental 
allocation are expected to demonstrate an understanding that when the 
experiment ends, the allocation will be returned; a successful 
experiment may need a new allocation under normal policies in order to 
continue in production or commercial use, but will not retain the 
experimental allocation.


A "publicly accessible document" is a document that is publicly and 
openly available free of charges and free of any constraints of 
disclosure.


ARIN will not recognize an experimental activity under this policy if 
the entire research experiment cannot be publicly disclosed.


ARIN has a strong preference for the recognition of experimental 
activity documentation in the form of a document which has been 
approved for publication by the IESG or by a similar mechanism as 
implemented by the IETF.


Proposed text:

11.1. Eligibility Criteria for Recognized Experimental Activity

The eligibility criteria for a recognized experimental activity under 
this policy are:


  * The experiment’s description and objectives are published in a
publicly accessible document, which for the purpose of this policy
means that the document is readily available free of charges to
the public, and free of any constraints of disclosure within one
year after the end of the experiment;
  * The experiment’s outcomes must also be published in a publicly
accessible policy;
  * Demonstration to ARIN that the experimental activity is
technically sound within the meaning of ARIN’s Policy Development
Process;
  * Demonstration to ARIN that the experimental activity is
technically coordinated in that consideration of any potential
negative impact of the proposed experiment on the operation of the
Internet and its deployed services has been considered, and a
description of experimenter mitigation plans to 

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

[Andrew Dul]

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 contacti...@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] Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilizatio

[Andrew Dul]

ARIN Draft Policy 2021-6 was retitled earlier this year as “Permit IPv4 
Leased Addresses for Purposes of Determining Utilization for Future 
Allocations” and the text was also updated based upon feedback from the 
community at the Fall 2021 meeting.


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

The draft did not receive sufficient support in the shepherds opinion to 
move this policy toward a recommended draft policy. Since this time the 
shepherds have been discussing with various members of the Internet 
Community and the ARIN AC on a possible path forward for this draft policy.


One of the ideas was to take a look at the problem statement and perhaps 
update and clarify the problem statement in hopes that this process 
would provide additional ideas to move the process forward.


The current draft policy problem statement is as follows:

Problem Statement: Current ARIN policy prevents the use of leased-out 
addresses as evidence of utilization.


Some contributors have suggested that there are perhaps two or more 
issues that are attempting to be solved here.


    Organizations would like the ability to lease some of their address 
space and not limit the receipt of future IPv4 transfers due the fact 
that ARIN’s evaluation of utilization considers leased space today to be 
unused.


    Organizations who wish to obtain address space are not able to 
pledge the address space as collateral in a financial transaction.  The 
RSA and ARIN policy today limit the ability of IPv4 address resources to 
be transferred to another party (financier) without that party showing 
need for use on an operational network.



We invite your feedback on these thoughts and ideas to help us rework 
the problem statement and future policy language solving these issues.


In particular, do you believe the problem statement needs to be 
rewritten to clarify the issue the Internet Community is trying to solve 
here?


If so, what problem or problems do you believe that the Internet 
Community needs to solve and what problem statement(s) make sense to 
restart the conversation around this topic?


Thanks in advance for your feedback,

Andrew

___
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-2022-8: Streamlining Section 11 Policy Language

[Andrew Dul]

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


Thanks in advance for your feedback on this draft.

Andrew

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


On 21 July 2022, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-316: Streamlining Section 11 Policy Language" as a Draft 
Policy.


Draft Policy ARIN-2022-8 is below and can be found at:

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

You are encouraged to discuss all Draft Policies on PPML. The AC will 
evaluate the discussion to assess the conformance of this draft policy 
with ARIN's Principles of Internet number resource policy as stated in 
the Policy Development Process (PDP). Specifically, these principles are:


* Enabling Fair and Impartial Number Resource Administration

* Technically Sound

* Supported by the Community

The PDP can be found at:

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

Draft Policies and Proposals under discussion can be found at: 
https://www.arin.net/participate/policy/drafts/


Regards,

Sean Hopkins

Senior Policy Analyst

American Registry for Internet Numbers (ARIN)

Draft Policy ARIN-2022-8: Streamlining Section 11 Policy Language

Problem Statement:

Section 11 of the NRPM contains a great deal of language that is 
either explicitly not policy, or is not impactful on ARIN’s 
administration of Internet number resources for experimental 
allocations, or to the customers requesting said resources. A revision 
to transform Section 11 into a collection of policies for experimental 
allocations serves to make the Section more easily digested by the 
reader, and a more functional reference for customers and ARIN staff 
during experimental allocation requests.


Policy statement:

Section 11 overview

Current text:

Experimental Internet Resource Allocations

ARIN will allocate Numbering Resources to entities requiring temporary 
Numbering Resources for a fixed period of time under the terms of 
recognized experimental activity.


“Numbering Resources” refers to unicast IPv4 or IPv6 address space and 
Autonomous System numbers. The following are the criteria for this policy:


Proposed text:

ARIN will allocate Numbering Resources to entities requiring temporary 
Numbering Resources for a fixed period of time under the terms of 
recognized experimental activity. “Numbering Resources” refers to 
unicast IPv4 or IPv6 address space and Autonomous System numbers.


The following are the criteria for this policy:

Section 11.1

Current text:

11.1. Documentation of Recognized Experimental Activity

A Recognized Experimental Activity is one where the experiment’s 
objectives and practices are described in a publicly accessible 
document. It is a normal requirement that a Recognized Experimental 
Activity also includes the undertaking that the experiment’s outcomes 
be published in a publicly accessible document at the end of the 
experiment. The conditions for determining the end of the experiment 
are to be included in the document. Applicants for an experimental 
allocation are expected to demonstrate an understanding that when the 
experiment ends, the allocation will be returned; a successful 
experiment may need a new allocation under normal policies in order to 
continue in production or commercial use, but will not retain the 
experimental allocation.


A “publicly accessible document” is a document that is publicly and 
openly available free of charges and free of any constraints of 
disclosure.


ARIN will not recognize an experimental activity under this policy if 
the entire research experiment cannot be publicly disclosed.


ARIN has a strong preference for the recognition of experimental 
activity documentation in the form of a document which has been 
approved for publication by the IESG or by a similar mechanism as 
implemented by the IETF.


Proposed text:

11.1. Documentation of Recognized Experimental Activity

A Recognized Experimental Activity is one where the experiment’s 
description and objectives are described in a publicly accessible 
document. The experiment’s outcomes must be published in a “publicly 
accessible document” that is publicly and openly available free of 
charges and free of any constraints of disclosure. Outcomes must be 
published within one year after the end of the experiment. The 
conditions for determining the end of the experiment are to be 
included in the document. When the experiment ends, the allocation 
will be returned. A successful experiment may need a new allocation 
under normal policies in order to continue in production or commercial 
use, but will not retain the experimental allocation.


ARIN will not recognize an experimental activity under this policy if 
the entire research experiment cannot be publicly disclosed.


Section 11.2

Current text:

11.2. Technical Coordination

ARIN requires that a recognized experimental activity is able to 
demonstrate that the activity is 

Re: [arin-ppml] Draft Policy ARIN-2022-3: Remove Officer Attestation Requirement for 8.5.5

[Andrew Dul]

On a related attestations, but weren't in the NRPM, in 2021 ARIN 
conducted a consultation on the state of attestations for other 
operational practices.


Consultation on Retiring the Officer Attestation Requirement
https://lists.arin.net/pipermail/arin-consult/2021-August/thread.html

While I see that the consultation was closed, I don't recall an 
announcement about any changes being made after this consultation, but I 
could have missed it.


Could ARIN staff please clarify the changes that were or weren't made 
after the consultation closed last year.


Thanks,
Andrew

On 6/21/2022 6:56 PM, ARIN wrote:


On 16 June 2022, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-309: Remove Officer Attestation Requirement for 8.5.5" as a 
Draft Policy.


Draft Policy ARIN-2022-3 is below and can be found at:

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

You are encouraged to discuss all Draft Policies on PPML. The AC will 
evaluate the discussion to assess the conformance of this draft policy 
with ARIN's Principles of Internet number resource policy as stated in 
the Policy Development Process (PDP). Specifically, these principles are:


* Enabling Fair and Impartial Number Resource Administration

* Technically Sound

* Supported by the Community

The PDP can be found at:

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

Draft Policies and Proposals under discussion can be found at: 
https://www.arin.net/participate/policy/drafts/


Regards,

Sean Hopkins

Senior Policy Analyst

American Registry for Internet Numbers (ARIN)

Draft Policy ARIN-2022-3: Remove officer attestation requirement for 8.5.5

Problem Statement:

Requiring an officer attestation requires unnecessary resources and 
increases the time to complete an IPv4 transfer.


Policy statement:

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.


Removing “An officer of the organization shall attest to the 
documentation provided to ARIN.”


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 contacti...@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-8: Deprecation of the 'Autonomous System Originations' Field

[Andrew Dul]

On 4/26/22 5:45 PM, Martin Hannigan wrote:



On Tue, Apr 26, 2022 at 6:20 PM Andrew Dul  wrote:

Legacy holders have the option to add records to ARIN’s
authenticated irr. It only requires them to sign an lrsa or rsa.
In my opinion it is time for the free ride for legacy holders to end. 



Then why doesn’t ARIN make it easy for them to not risk losing their 
pre-ARIN allocation? Could you offer us all a diff between how APNIC, 
RIPE and any other RIR handles this and compare to the L/RSA?


Ripe's published services to legacy holders is documented here

https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders

APNIC's calls these historical resources and its policies are noted 
here.  APNIC will also require historical resource holders to become 
members effects Jan 1, 2023.


https://help.apnic.net/s/article/Historical-resources

https://blog.apnic.net/2021/03/26/rpki-services-now-available-to-apnic-historical-resource-holders/




Thanks Andrew,

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

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

[Andrew Dul]

Legacy holders have the option to add records to ARIN’s authenticated irr. It 
only requires them to sign an lrsa or rsa. In my opinion it is time for the 
free ride for legacy holders to end. 

I have no problem with a sunset date say 2-5 years from now but we need to move 
in that direction. 

Speaking only for myself and not for any organization or in any position. 

Andrew


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

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

[Andrew Dul]

"To use an AS Number to interconnect with other Autonomous Systems." was 
intended to apply to situations where a public ASN number was desired 
for exchanging routes between organizations but where the concept of an 
"upstream provider" wasn't appropriate.  An example might be if an there 
were two or more organizations which are exchanging routes, but the 
organizations wanted unique AS Numbers to ensure there are not any AS 
number collisions.


Hope this helps,
Andrew

On 3/22/2022 10:46 AM, Owen DeLong via ARIN-PPML wrote:

Can someone clarify for me the meaningful difference between:

To originate announcement of IP Number Resources via an accepted 
protocol (such as Border Gateway Protocol) from an AS Number different 
than that of its upstream provider;


and

To use an AS Number to interconnect with other Autonomous Systems.

—

It seems to me that anything defined by the first sentence would be 
encompassed in the second.


Further, while I admit my imagination may be limited here, I am unable 
to imagine a useful implementation of the second sentence that would 
not also conform to the first and would require a unique non-private ASN.


While I can see useful instances for receive-only (non-originating) 
BGP sessions, such as route servers, etc., I’m hard pressed to see why 
they would need a unique public ASN. Even if they do, a useful route 
server is, by definition, multi-homed.


Not necessarily opposed to the policy as written, but think that it’s 
a lot of extra words with little actual value in terms of clarity and 
perhaps even muddying the waters a bit.


Owen



On Mar 22, 2022, at 09:04, ARIN  wrote:

On 17 March 2022, the ARIN Advisory Council (AC) advanced the 
following Draft Policy to Recommended Draft Policy status:


* ARIN-2021-3: Private AS Number and Unique Routing Policy Clarifications

The text of the Recommended Draft Policy is below, and may also be 
found at:


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

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
Senior Policy Analyst
American Registry for Internet Numbers

Recommended Draft Policy ARIN-2021-3: Private AS Number and Unique 
Routing Policy Clarifications


AC Assessment of Conformance with thePrinciples of Internet Number 
Resource Policy 
:
Recommended Draft Policy ARIN-2021-3 conforms to the principles of 
the ARIN Policy Development Process as follows:
- By providing greater clarity concerning when a requesting 
organization qualifies for AS Numbers, it promotes fair and impartial 
number resource administration;
- It is technically sounds because it clarifies the technical 
requirements for obtaining AS Numbers (i.e., the need to interconnect 
with other organizations’ Autonomous Systems, what constitutes a 
“unique routing policy”, and the need to have a network plan); and
- Community support has been demonstrated throughout the process 
associated with its development.

Problem Statement:
At ARIN 47, staff identified three points of potential confusion with 
current text in NRPM Section 5: AS Numbers.
“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 unique AS Numbers depends upon their need 
(or lack thereof) to interconnect with other organizations’ 
Autonomous Systems.
“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 AS 
Numbers under the “unique routing policy” requirement, because they 
don’t understand what “unique routing policy” actually means in practice.
“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 AS Numbers. Additionally, clarification that 
some organizations may have a unique need for an AS Number outside of 
utilizing a unique routing policy, such as one implemented using, for 
example, a protocol such as Border Gateway Protocol (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
“If a unique AS Number is not required 

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

[Andrew Dul]

The draft policy as currently written does not provide any additional 
limits against speculation.  As drafted, it allows any organization 
(including those who do not operate networks) to obtain IPv4 addresses 
for the purpose of leasing.


With that policy change what types of limits does the community think 
would be needed?


Thanks,
Andrew

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


-Scott

On Thu, Mar 17, 2022 at 1:33 PM Owen DeLong via ARIN-PPML 
 wrote:





On Mar 16, 2022, at 15:22 , Fernando Frediani
 wrote:

Hi David

If I understand correctly you seem to have a view that there
should be a ARIN policy to permit IPv4 leasing just because it is
a reality and we kind of have to accept it in our days. No we
don't, and that's for many different reasons.


Well, of course, you are free to deny reality as much as you want.
Many people do. It’s not particularly helpful in the discussion,
however.


I am used to see people saying the brokers are doing a good thing
for the community by facilitating the things which in reality is
the opposite. It may look like a good things, but the real
beneficiaries are only them who profit from it without much
concern of what is fair or not to most organizations involved.



You are actually mistaken here. I used to think as you do,
actually. I was very resistant to the first “specified transfer”
policies because of some of the reasons you describe. However,
what you are failing to recognize is that:
+Brokers and specified transfers were going to happen with or
without the RIRs. If they happened without the RIRs,
there’d be no accurate record of who was using which address space
and the provenance of addresses would be
very difficult to support or defend.

*Benefit to the community from brokers: (ethical) brokers are
familiar with the rules in the RIRs in which
they operate and can assist their customers in accurate and
compliant registration updates and
aid in keeping the allocation database(s) accurate.

+With the economic realities of IPv4 addresses becoming
progressively more and more expensive and the advent
of ISPs with limited IPv4 resources available, it is inevitable
that more and more IP service providers will be
doing one or more of the following:

+Separate surcharges for IPv4 addresses
+Expecting customers to supply their own IPv4 addresses
+Surcharges for IPv4 services
+IPv4 “installation charges” large enough to cover the procurement
of addresses

*Brokers assist ISPs and customers in many of the above circumstances.

+With a variety of organizations holding IPv4 addresses that may
or may not even known they have them and whose
IPv4 resources may vastly exceed their needs, it is (arguably)
desirable to have those addresses be transferred to parties
that have current need for IPv4 addresses.

*Brokers provide a valuable service to the community identifying
and marketing these resources
*Paid transfers provide an incentive for entities to make more
efficient use of the resources they have in order
to monetize the resources they no longer need. Brokers are
frequently able to assist in this process.

+With the high cost of acquisition, IPv4 addresses have become a
capital intensive part of any network-dependent
business model that must support IPv4. Further, there is some risk
that this capital outlay may be fore a resource
which will abruptly and quickly lose its value and no longer be
needed well before it can be amortized as a capital
expenditure. As such, it may make sense for some entities to
transfer that risk to another organization by using
a lease structure instead of purchasing the addresses outright.

*Brokers that provide IPv4 leasing in an ethical and policy
compliant way provide a valuable service
to these businesses. Yes, their price per address may eventually
be more than it would have cost
them to purchase the addresses, but the same is true of virtually
any rental situation.  On the other hand,
that excess helps offset the risk that the lessor is taking by
owning a resource that 

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

[Andrew Dul]

I'd like to propose another option for the last part of section5, to 
make it clear that a planning and implementation period is permissible.



"AS Numbers shall be issued to organizations meeting section 5 criteria 
and up to 12 months prior to planned implementation on their network."




On 3/8/2022 7:54 PM, Owen DeLong via ARIN-PPML wrote:
I’m fine with all but the last change… The new wording is potentially 
more problematic than the old wording in that “current need” might 
imply that one needs to already be multi homed before one can get an 
ASN, which creates a bit of a catch-22 which is the reason for the “or 
immediately become…” language.


I suggest instead that we consider the following:

AS Numbers are based on current need, as set out in this section 5. 
However, a site which plans to begin exchanging inter domain routing 
protocols with other autonomous systems upon receipt of the ASN 
requested is considered to have current need.


This would, IMHO, have the clarifying effect which is sought in the 
problem statement.


Owen



On Mar 8, 2022, at 06:51, ARIN  wrote:

The following Draft Policy has been revised:
* ARIN-2021-3: Private AS Number and Unique Routing Policy Clarifications
Revised text 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 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.
“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 unique AS Numbers depends upon their need 
(or lack thereof) to interconnect with other organizations’ 
Autonomous Systems.
“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 AS 
Numbers under the “unique routing policy” requirement, because they 
don’t understand what “unique routing policy” actually means in practice.
“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 AS Numbers. Additionally, clarification that 
some organizations may have a unique need for an AS Number outside of 
utilizing a unique routing policy, such as one implemented using, for 
example, a protocol such as Border Gateway Protocol (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
“If a unique AS Number is not required for a given network design, 
one or more of the AS Numbers reserved for private use should be 
utilized.”

Replace
“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) 2. A multihomed site”

with
“In order to be assigned an AS Number, each requesting organization 
must provide ARIN with verification that it requires a unique routing 
policy, such as a plan:
    To originate announcement of IP Number Resources via an accepted 
protocol (such as Border Gateway Protocol) from an AS Number 
different than that of its upstream provider;

    To multihome a site with one or more Autonomous Systems; or
    To use an AS Number to interconnect with other Autonomous Systems.”
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 are issued based on current need, as set out in this 
section 5.”

___
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-2021-7: Make Abuse Contact Useful

[Andrew Dul]

On 10/27/2021 12:26 AM, William Herrin wrote:

On Tue, Oct 26, 2021 at 5:33 PM Andrew Dul  wrote:

I'd might be ok with a URL, but not just "any URL" if the community is
really interested in improving reporting, we likely need a structured
data format and API so that input can be better used by those receiving
the reports.

Hi Andrew,

I'd prefer not to see ARIN leading that effort but I'd point out that
this policy change creates a framework which could lead to such
standardization. If the URL is HTTP, automation could request the URL
with a particular user agent string which, if the server supports it,
would return machine-readable instructions for generating and
transmitting a report instead of the normal human-readable ones.


While ARIN it probably not the best place to formalize this standard 
'structured data format' it certainly can be involved in creating and 
advocating for its development and standardization. In the same way that 
RDAP was developed by RIR staff and then standardized in the IETF.


In this case, if we build it (a URL option)...they will come...in many 
many different and likely incompatible ways which is worse that today's 
email standard.


I'm disinclined to support this draft to allow a URL as a reporting 
mechanism in the absence of the structured data format.


Thanks,

Andrew

___
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

[Andrew Dul]

Email as a reporting mechanism does seem old these days.

I'd might be ok with a URL, but not just "any URL" if the community is 
really interested in improving reporting, we likely need a structured 
data format and API so that input can be better used by those receiving 
the reports.


Andrew


On 10/26/21 2:59 PM, John Santos wrote:
My domain has a valid abuse contact (me), and it's been years since I 
actually received anything except spam.  (I check the spam detector 
output daily to make sure it actually is spam, and it always is.  It's 
usually no more than a handful of spam emails daily, probably because 
I never respond to it or originate any email from the "abuse" address, 
so there is nothing for the spammers to harvest.)


Under this new scheme, would I still be able to handle abuse the exact 
same way?  Or would we be required to create a web page solely to 
provide an email address and phone number for abuse reporting, 
duplicating what is already in whois?


BTW, our fairly extensive web site is almost entirely private, with 
only a half dozen or so public pages of simple, static information.  
Which are inaccessible if our Internet access or electrical power is 
down.


In other words, any change for us would be a pain the keister for no 
discernible benefit to us or any one else.


Unless this is a NO-OP, my vote is NO.



On 10/26/2021 4:18 PM, ARIN wrote:
On 21 October 2021, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-303: Make Abuse Contact Useful" as a Draft Policy.


Draft Policy ARIN-2021-7 is below and can be found at:

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



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-7: Make Abuse Contact Useful

Problem Statement:

ARIN’s process of attaching an abuse contact to resource records is 
of limited utility. The phone number is often an unmanned voicemail 
that refers the caller to a web page while the email address is 
commonly an auto-responder which does the same. Because the emails 
often involve problematic content they can get lost in filters making 
it hard to even find the URL let alone get an abuse report to go 
through. This is further exacerbated by folks who write programs to 
automatically generate unverified abuse reports and email them to the 
ARIN contact, flooding the mailbox with useless reports that no human 
being is assigned to look through.


With responsible network providers, the process for dealing with 
network abuse instead usually starts with a web page. The web page 
provides instructions and may offer forms for describing the abuse 
and uploading supporting material of the nature that the service 
provider needs in order to take action.


It would be helpful for ARIN to support the abuse reporting process 
they actually use.


Policy statement:

Strike -

 From 2.12 “and one valid abuse”

 From 3.6.2 “Abuse”

Add:

2.1.2 To “organization information must include…zip code equivalent,” 
add “an abuse reporting URL”


4.2.3.7.3.2: replace “upstream Abuse and Technical POCs " with 
“upstream Technical POCs and URLs for reporting abuse”


6.5.5.3.1: replace “upstream Abuse and Technical POCs " with 
“upstream Technical POCs and URLs for reporting abuse”


Timetable for implementation: Whenever

Anything Else:

Initial implementation suggested to replace the abuse POC with a URL 
pointing to ARIN’s display of the same POC record which was used for 
abuse reporting. Should support multiple URLs so that if desired an 
organization can specify both “mailto:somebody@here” and 
“tel:1234567” if that’s how they actually want abuse reported to them.



___
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 

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

[Andrew Dul]

In a 32-bit ASN world..in cases where one might choose to use a 
private-asn, such as being multi-homed to the same provider, if an 
organization wants to use a public ASN we shouldn't discourage that 
through policy, as it also allows an organization to easily become BGP 
multihomed in the future.


Andrew

On 7/21/2021 5:11 PM, Martin Hannigan wrote:


I’m not endorsing anything, but the remarks that Chris regarding the 
content he commented on were good observations that are typical of our 
lack of writing standards for the NRPM. I could see budget being spent 
on improving that.


Andrew: How does a public 32 bit ASN reduce the need to use a private ASN?

Warm regards,

-M<


On Wed, Jul 21, 2021 at 4:38 PM Andrew Dul <mailto:andrew@quark.net>> wrote:


Based upon the input we have received from ARIN staff it seems that
additional clarity is desired in section 5 for ASN assignments.

I am not convinced however that the current draft text is the best
way
to fix the issues raised so far.  I don't have specific test
suggestions
at this point but believe we should discuss how the text should be
improved in light of how ASNs are now being used by various cloud
providers and the fact that ASNs are now 32-bits in length which
in many
cases reduces the need to use private AS numbers.

Andrew

On 7/20/2021 5:23 PM, Chris Woodfield wrote:
> 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 mailto:i...@arin.net>> 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/
<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/
<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-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 

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

[Andrew Dul]

Based upon the input we have received from ARIN staff it seems that 
additional clarity is desired in section 5 for ASN assignments.


I am not convinced however that the current draft text is the best way 
to fix the issues raised so far.  I don't have specific test suggestions 
at this point but believe we should discuss how the text should be 
improved in light of how ASNs are now being used by various cloud 
providers and the fact that ASNs are now 32-bits in length which in many 
cases reduces the need to use private AS numbers.


Andrew

On 7/20/2021 5:23 PM, Chris Woodfield wrote:

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 

Re: [arin-ppml] Revised - Draft Policy ARIN-2020-11: Add Textual Description for the Number Resource Hierarchy Image in Section 2

[Andrew Dul]

This draft is intended to be moved out of draft policy as an editorial 
update.


The text has been updated based upon suggestions on PPML and in the AC.  
We will quickly present an update on this next week at the meeting and 
then I intend to move this forward as an editorial update unless there 
are other issues which are raised by the current text.


Thanks,

Andrew

On 4/7/2021 11:59 AM, John Santos wrote:
Strangely, this just arrived a few minutes ago, even though the 
timestamp is almost two weeks ago!?


I support this in concept.  However, isn't it just an editorial change 
and thus not requiring the full-blown policy process?


-- John Santos


On 3/26/2021 8:19 AM, ARIN wrote:

The following Draft Policy has been revised:

* ARIN-2020-11: Add Textual Description for the Number Resource 
Hierarchy Image in Section 2


Revised text is below and can be found at:

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

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-2020-11: Add Textual Description for the Number 
Resource Hierarchy Image in Section 2


Problem Statement:

The beginning of Section 2 in the NRPM shows a diagram of how 
addressing responsibility is delegated. However, this image does not 
appear to have a description or even alt text, and the actual text is 
not selectable. This could have accessibility implications, 
especially those with sight-related disabilities, or if the NRPM is 
translated into other languages.


Policy statement:

Proposal: Add the following text before the image in Section 2:

Responsibility for management of number resources is distributed 
globally in accordance with the following procedures:


* Global number resource management is performed by the Internet 
Assigned Numbers Authority (IANA). IANA distributes number resources 
to RIRs (AfriNIC, APNIC, ARIN, LACNIC, and the RIPE NCC), but not 
directly to LIRs (Local Internet Registries) or end users.


* RIRs, such as ARIN, distribute number resources to LIRs and 
directly to end-user organizations.


* LIRs may further delegate number resources to other LIRs, as well 
as to other end-user organizations.


Replace the text “ISP Internet Service Provider” in the graphic with 
the text “LIR Local Internet Registry”


Timetable for implementation: Immediate


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




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

Re: [arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation “Swap” Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers

[Andrew Dul]

I believe swaps should not be permitted using wait-list space.  I do not 
support this draft when using wait-list space for a swap.


I could support the draft if the ability to use wait-list space for the 
swap is removed.


Speaking only for myself,
Andrew

On 12/15/2020 11:38 AM, Owen DeLong wrote:

Dear ARIN community,

We (the AC, and specifically the proposal shepherds) need to solicit some 
additional feedback in order to better know the community’s desire with regards 
to this policy. Specifically, we’d like to ask the following questions:

1a. Do you feel that we should place an upper limit on the size of the 
smaller block
received in the process?

1b. If so, what should that upper limit be?

2.  Do you support limits on the time period allowed for renumbering?

2a. If so, how long?

2b. If so, what consequences should there be for exceeding the time 
limit?

3.  Should any additional restrictions or prohibitions be placed on use of 
waitlist
space in these transactions?

3a. Restrictions on waitlist providing the smaller block?

3b. Restrictions on waitlist space being transferred out?

4.  Do you support the policy as currently written?

5.  If not, would you support it with the changes suggested in your answers 
above?

Thanks for your attention to this matter,

Owen DeLong
ARIN AC

___
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-2: Reinstatement of Organizations Removed from Waitlist by Implementation of ARIN-2019-16

[Andrew Dul]

This draft policy while allowing 26 organizations which have up /18 in
holdings to obtain a /22 under this policy, blocks 11 organizations
which had more than a /18 and thus are not eligible to obtain a /22 even
though they waited in line too.   By the logic below this policy isn't
fair to these 11 organizations.  They waited in line too.

While I understand why these organizations would support this policy,
its in their direct monetary interest.

I still believe the AC got the new policy right by limiting the
wait-list to smaller organizations (which hold a /20 or less).  The
wait-list was never a guarantee of getting address space. 

I still don't support this policy.

For the record...ARIN staff didn't bring this policy, member(s) of the
Internet community started this policy proposal.  They were right to do
so and the discussion is certainly worthwhile.  But the Internet
community develops policy via the PDP not ARIN staff.  
https://www.arin.net/participate/policy/pdp/

Andrew

On 10/22/2020 6:50 AM, Brandt, Jason via ARIN-PPML wrote:
>
> It has nothing to do with current allocations or shortages.  It has
> everything to do with proper application of current policy and
> honoring existing policy when changes are made.  How would you like to
> stand in line at the store with your groceries for an hour, then be
> told you can't have that many items and go to the back of the line
> since they just changed their policy?  It's not a fair application. 
> These organizations followed the rules that were there at the time and
> did everything they were supposed to, and were APPROVED to wait for
> the next available allocation.  Then due to a policy change they were
> later removed from the list and told to apply again.  When you have
> policies, they need to be honored as written, and changes made need to
> be applied moving forward, and not retroactively. 
>
>  
>
> Jason​ 
>   Brandt   
>   Senior Systems Engineer
>
> Pearl Companies    |  1200 E Glen Ave     Peoria Heights  
> ,   IL   
> 61616
>
> P:    *309.679.0184*    F:  *309.688.5444*
>     E:  *jason.bra...@pearlcompanies.com*
> 
>
> *www.pearlcompanies.com | I*
> nsurance ‑ Technology ‑ Automotive
>
> PEARL COMPANIES CONFIDENTIALITY: This communication, including
> attachments, is for exclusive use of the addressee(s) and may contain
> proprietary, confidential or privileged information. If you are not
> the intended recipient, any use, copying, disclosure, or distribution
> or the taking of any action in reliance upon this information is
> strictly prohibited. If you are not the intended recipient, please
> notify the sender immediately and delete this communication and
> destroy all copies [v1.0.002].
>
> *From:*ARIN-PPML  *On Behalf Of *Fernando
> Frediani
> *Sent:* Thursday, October 22, 2020 08:45
> *To:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Last Call - Recommended Draft Policy
> ARIN-2020-2: Reinstatement of Organizations Removed from Waitlist by
> Implementation of ARIN-2019-16
>
>  
>
>
>   
>
> *CAUTION:*This email originated from outside the organization. Do not
> click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> What is this ?
>
> People coming to support this just because they see a opportunity to
> get a few more space for their own organizations and not because this
> is a fair and equitable to all existing and potential members of the
> Internet Community.?
>
> Everybody that operates in the Internet Business depends on IPv4
> allocations and they are not available anymore. This shortage is equal
> to anyone and some still wishing to receive a little chunk of
> addresses despite the situation that affects all ?
> What is the justification to give some organizations who already have
> some reasonable space to work with, more space in current times ? I
> see this as privileging few rather than been equalized to all others.
>
> So why I always opposed this proposal.
> Fernando
>
>  
>
> On 22/10/2020 09:51, Jon Bachtold wrote:
>
> I fully support this policy as written, I appreciate how the ARIN
> staff has determined this issue a definite oversight and has
> determined to quickly remedy.
>
>  
>
> As a Regional ISP, we live and breathe on IPV4 allocations and
> responsible allocations to our customers.   I am impressed by the
> tremendous response of colleagues, partners, employees, customers,
> and competitors of Stratus in reaction to this.  That tells me
> that they all had the same reaction when they were advised of the
> situation, disappointment, and dare I say some outrage.     
>
>  
>
> Equally, I am impressed that ARIN staff responded so quickly, and
> they look to remedy the situation quickly,  preventing any tarnish
> to the reputation that it has achieved as a 

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

[Andrew Dul]

On 10/12/2020 4:43 PM, sc...@solarnetone.org wrote:
> Hi Andrew,
>
>>> 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.
>>
>>
>
> From https://www.arin.net/resources/fees/fee_schedule subsection 'End
> Users with Registration Services Plan':  "Organizations that choose to
> convert to the Registration Services Plan will be evaluated as an ISP
> from a policy perspective when requesting future Internet number
> resources from ARIN."  While this _may_ be intended to indicate that
> they will be billed based on the ISP fee schedule for additional
> resources, it in effect can (and may be intended to) indicate that in
> all number policy related matters, they will be viewed as an ISP.

Well, the one-way aspect of this choice to move to the End User w/
Registration Services Plan and the reevaluation as an ISP for policy
purposes is additional information to me in this discussion.

JS, is the one-way option documented publicly (other than where you just
did so on PPML) ?

I can see why from a $ perspective this may be valuable to an
organization at one point in time.  I can also see where down the road
it could go the other way for an organization. 

In general, I don't think its probably a good idea to reclassify
organizations as "ISPs" for policy purposes when they do so primarily
for fee purposes, especially with regard to IPv6 policy.  

For example, an "end-user" organization had some IPv4, an ASN, and an
IPv6 /48.  And at some point opted to be a Registration Services Plan
End-User.  Now suppose they wanted to get another /48 for a different
distinct location (non-connected, but also multi-homed), well that would
not be permissible under policy because they are now an ISP, and they
would need to get a least a /36 under current policy and they probably
wouldn't qualify for anything because the subsequent allocation
requirements for ISPs in 6.5.3 are quite high.

There seems to be some unintended potential long-term negative
consequences to the one-way option with end-user registration services
plan and force application of ISP policy onto primarily end-user
organizations.


Andrew


___
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

[Andrew Dul]

>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 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] Draft Policy ARIN 2020-3

[Andrew Dul]

On 10/12/2020 2:30 PM, sc...@solarnetone.org wrote:
> Andrew,
>
> On Mon, 12 Oct 2020, Andrew Dul wrote:
>
>> On 10/12/2020 1:29 PM, sc...@solarnetone.org wrote:
>>> Hi Andrew,
>>>
>>> On Mon, 12 Oct 2020, Andrew Dul wrote:
>>>
>>>> The partial returns language is also intended to promote best
>>>> practices
>>>> for IPv6 addressing, that is giving big blocks to allow ISPs to assign
>>>> /48s to all customers.
>>>
>>> True, but not all resource holders are operating ISP's for public use.
>>> For example, my local City Government has an ASN, and v4 address
>>> block. They provide no internet services, neither network, to eyes,
>>> nor content other than for their own use.  This is the case with many
>>> resource holders not in the primary business of being an ISP.
>>>
>>> Scott
>>>
>> The organization you describe here sounds more like an end-user, but I
>> do understand various organizations have switched from being an end-user
>> to ISP and vise-versa over the years for various reasons. 
>
> 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.


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

An ARIN end-user customer can have an ASN as part of their number
resources and can be multihomed.  We specifically added the 6.5.8
section so that IPv6 end-users could multihome.  Prior to the addition
of this section in the the IPv6 policy it was assumed that end-users
couldn't/shouldn't? multihome so they either had to get an ISP sized
allocation or use some other (SHIM6/etc) method to multihome.

I have worked & consulted for organizations who were ARIN end-users and
had AS and number resources.

Andrew



>>
>>
>>>>
>>>> Andrew
>>>>
>>>> On 10/12/2020 12:26 PM, sc...@solarnetone.org wrote:
>>>>> Hi Chris,
>>>>>
>>>>> I wonder what percentage of 2x-small Resource holders have a /24 of
>>>>> v4, and would otherwise qualify for 3x-small status but for their v6
>>>>> allocations, and what percentage of all ASs registered with ARIN that
>>>>> represents.  This represents the the total who could "downgrade" to a
>>>>> nano-allocation, were that a option.  It would be easy to derive from
>>>>> that the maximum effect on ARIN's finances, if they all chose to take
>>>>> that option.
>>>>>
>>>>> Scott
>>>>>
>>>>> On Mon, 12 Oct 2020, Chris Woodfield wrote:
>>>>>
>>>>>> 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
>>>>

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

[Andrew Dul]

On 10/12/2020 1:29 PM, sc...@solarnetone.org wrote:
> Hi Andrew,
>
> On Mon, 12 Oct 2020, Andrew Dul wrote:
>
>> The partial returns language is also intended to promote best practices
>> for IPv6 addressing, that is giving big blocks to allow ISPs to assign
>> /48s to all customers.
>
> True, but not all resource holders are operating ISP's for public use.
> For example, my local City Government has an ASN, and v4 address
> block. They provide no internet services, neither network, to eyes,
> nor content other than for their own use.  This is the case with many
> resource holders not in the primary business of being an ISP.
>
> Scott
>
The organization you describe here sounds more like an end-user, but I
do understand various organizations have switched from being an end-user
to ISP and vise-versa over the years for various reasons. 

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

This draft policy ARIN-2020-3 is specifically related to ISPs.


>>
>> Andrew
>>
>> On 10/12/2020 12:26 PM, sc...@solarnetone.org wrote:
>>> Hi Chris,
>>>
>>> I wonder what percentage of 2x-small Resource holders have a /24 of
>>> v4, and would otherwise qualify for 3x-small status but for their v6
>>> allocations, and what percentage of all ASs registered with ARIN that
>>> represents.  This represents the the total who could "downgrade" to a
>>> nano-allocation, were that a option.  It would be easy to derive from
>>> that the maximum effect on ARIN's finances, if they all chose to take
>>> that option.
>>>
>>> Scott
>>>
>>> On Mon, 12 Oct 2020, Chris Woodfield wrote:
>>>
>>>> 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
>>>>>>>
>>>

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

[Andrew Dul]

The partial returns language is also intended to promote best practices
for IPv6 addressing, that is giving big blocks to allow ISPs to assign
/48s to all customers.

Andrew

On 10/12/2020 12:26 PM, sc...@solarnetone.org wrote:
> Hi Chris,
>
> I wonder what percentage of 2x-small Resource holders have a /24 of
> v4, and would otherwise qualify for 3x-small status but for their v6
> allocations, and what percentage of all ASs registered with ARIN that
> represents.  This represents the the total who could "downgrade" to a
> nano-allocation, were that a option.  It would be easy to derive from
> that the maximum effect on ARIN's finances, if they all chose to take
> that option.
>
> Scott
>
> On Mon, 12 Oct 2020, Chris Woodfield wrote:
>
>> 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 /4

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

[Andrew Dul]

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-2: Grandfathering ofOrganizations Removed from Waitlist by Implementation of ARIN-2019-16

[Andrew Dul]

I do not support the re-adding of organizations with any size of IPv4 
holdings back to the wait-list.


Speaking only for myself,

Andrew


On 8/18/2020 8:39 AM, Hayee Bokhari wrote:



Seems like a plan,

Go for it.

Regards
Hayee Bokhari
514-341-1579 Ex 212
800-427-6012 Ex 212
bokh...@cronomagic.com 
http://www.cronomagic.com

Hi all, Alyssa and I (co-shepherds for this policy) have reviewed
all of the comments. There are 18 comments in favour of the spirit
of this policy, and 5 against.


Many of these comments express support for removing the
restriction on total holdings for a grandfathered organization,
because this was not a restriction when they were originally
placed on the list.


As such, the amended proposal would look like this:


ARIN will restore organizations that were removed from the
waitlist at the adoption of ARIN-2019-16 to their previous
position (STRIKE THIS: 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.Thoughts?

-Anita Nikolich

On Fri, Jul 24, 2020 at 4:09 PM Isaiah Olson
mailto:isa...@olson-network.com>> wrote:

Hi all,

On behalf of my organization, I would also like to voice
support for this policy. As much as I find some arguments
against the policy compelling, namely that nobody is
guaranteed to receive any space within any kind of time frame
when using the waiting list, I think it’s pretty clear to the
community that an error was made in moving the target out from
underneath companies who had already been patiently waiting on
the list in accordance with the requirements at the time they
were added.

As far as implementation details, I absolutely believe that
two of the most important measures to prevent fraud were the
introduction of the /22 limit and the 60 month waiting period
to transfer wait list issued space. Although we may have erred
in retroactively removing orgs based on the new /20 limit for
total space held, I think that the grandfathered orgs should
be subject to the same treatment as the orgs who remained on
the list after 2019-16 was implemented. Otherwise, I believe
we would once again be creating a situation of unequal
treatment for the orgs who had to reduce their request size to
a /22 after the implementation of 2019-16, and were subject to
the new 60 month waiting period upon issuance.

With regards to the proposed /18 limit, I do find that there
is little to support this arbitrary boundary when the original
waitlist policy specified no such condition. Since we are
remedying a one time error, I think that we shouldn’t be too
particular about which of the aggrieved parties are allowed to
make use of that remedy. Although I personally believe that
most organizations holding greater than a /18 could probably
afford to obtain space in other ways, I think the duty of ARIN
to be fair and impartial requires us to take a bit broader
view. Asking an organization to take a smaller allocation, or
wait longer to transfer allocated space, seems to me to be a
much less onerous retroactive application of new policy than
drawing any boundary which results in complete ineligibility
for some.

Isaiah Olson

Olson Tech, LLC

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

Hi all, Alyssa and I (co-shepherds for this policy) have reviewed all 
of the comments. There are 18 comments in favour of the spirit of this 
policy, and 5 against.



Many of these comments express support for removing the restriction on 
total holdings for a grandfathered organization, because this was not 
a restriction when they were originally placed on the list.



As such, the amended proposal would look like this:


ARIN will restore organizations that were removed from the waitlist at 
the adoption of ARIN-2019-16 to their previous position (STRIKE THIS: 
if their total holdings of IPv4 address space amounts to a /18 or 
less.) The maximum 

Re: [arin-ppml] Draft Policy ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers

[Andrew Dul]

https://tools.ietf.org/html/rfc5533

As far as I know this concept wasn't really adopted or embraced by
network operators.

Andrew

On 7/16/2020 8:11 PM, hostmas...@uneedus.com wrote:
> Has there actually been any effort toward another routing method in
> IPv6 other than BGP?
>
> In theory, IPv6 should not require BGP for multihoming, unlike IPv4.
> According to the current IPv6 standards, one should be able to have
> more than one router from more than one provider on a LAN.  Each of
> these routers could assign a SLAAC/DHCP6 address/network to every
> host, providing each host with more than one route to the internet,
> using the IPv6 block of each upstream.  Thus, if this could properly
> work, IPv6 should be able to provide multihoming to each host with an
> address on the provider blocks, without the need of the customer site
> to use BGP or any other routing protocol.
>
> The problem is that the IPv6 stack in these hosts receiving
> advertisements from more than one router generally cannot deal with
> more than one default route, forcing all traffic from that host onto
> only one of the available networks.  This is not an easy fix, since it
> would require a change in the network stack of each host, rather than
> each network.
>
> I have more than one IPv6 upstream, with a /48 from each from their PA
> space.  In order to get this to work, I have to play games with the
> routing table with a cron script that checks for upstream connectivity
> and changes the routing tables accordingly. Other scripts for inbound
> connections alter the inbound DNS entries that are always advertised
> with a low TTL. It would be nice if ITEF could work out a true
> solution to this, as it would eliminate the need for most to have PI
> IPv6 space.
>
> Any news on if there has ever been any progress in this regard?  By
> splitting the upstream between more than one IPv6 provider, this would
> seem to to be a cleaner solution than BGP and IPv4.  I would rather
> have an RFC sanctioned solution to this problem.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
> On Thu, 16 Jul 2020, Owen DeLong wrote:
>
>> In general, I agree with your point. Perhaps “Customer must originate
>> prefix(es) and announce them via a border routing protocol (e.g.
>> BGP-4) to each of their
>> upstreams."
>>
>> In specific, I think it’s extremely unlikely that there will be any
>> significant advances or changes in IPv4 routing protocols as the IETF
>> has pretty thoroughly
>> expressed adesire to stop working on IPv4 except in furtherance of
>> transition to IPv6.
>>
>> Owen
>>
>>
>>   On Jul 16, 2020, at 11:06 , 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
>>  

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

[Andrew Dul]

I do not support the reintroduction of organizations onto the wait-list 
who were removed due to having existing address holdings larger than a 
/20.  Being on the wait-list was never a guarantee that you would 
receive space.  The AC had to balance the various elements of block size 
and organizations who would be eligible to receive space under the 
updated policy and we were aware that the rules as implemented would 
prevent some organizations on the wait-list from receiving blocks going 
forward.


Speaking only for myself, not the AC

Andrew

On 6/19/2020 11:25 AM, Alyssa Moore wrote:

Hi folks,

There was some great discussion of this policy proposal at ARIN45. We 
hear a wide range of views including:


 1. Don't grandfather organizations. The new waitlist policy is sound.
 2. Organizations that were on the waitlist before 2019-16 should be
eligible for their original request size (even if it exceeds the
new limit of a /22).
 3. Organizations that were on the waitlist before 2019-16 should
remain eligible if their holdings exceed a /20 OR a /18. The draft
policy under discussion specifies a /18 total holdings for
grandfathered orgs, while the current waitlist policy (2019-16)
specifies a /20.
 4. Organizations that were on the waitlist before 2019-16 should be
eligible regardless of their total holdings because that was not a
restriction of the policy under which they originally qualified
for the waitlist.

 There was general support to continue finessing this draft. If you 
have views on the above noted parameters, please make them known here.


For reference:

*Old waitlist policy*

 1. Requester specifies smallest block they'd be willing to accept,
equal to or larger than the applicable minimum size specified
elsewhere in ARIN policy.
 2. Did not place a limit on the total existing IP address holdings of
a party eligible for the waitlist.
 3. Made resources issued from the waitlist ineligible for transfer
until after a period of 12 months.

*New Waitlist Policy*

 1. Limits the size of block ARIN can issue on the waitlist to a /22.
 2. Places a limit on the total existing IP address holdings of a
party eligible for the waitlist at a /20 or less.
 3. Makes resources issued from the waitlist ineligible for transfer
until after a period of 60 months.


Best,
Alyssa

On Thu, Mar 26, 2020 at 3:35 PM David Farmer > wrote:


I support this policy and believe the policy development process
is the proper place to handle this issue. However, this policy
seems to be implementable as a one-time policy directive to ARIN
Staff. Once implemented, by putting the
effected organizations back on the waiting list, it seems
unnecessary to memorialized the text in the NRPM, it would
immediately become extraneous and potentially confusing to future
readers of the NRPM.

Therefore, I would like to recommend the Policy Statement not be
added to the NRPM upon its implementation. I believe this to
be consistent with the intent of the policy.  Otherwise, does ARIN
Staff have procedural advice on how best to handle what seems like
a one-time directive?

Thanks

On Tue, Mar 24, 2020 at 12:21 PM ARIN mailto:i...@arin.net>> wrote:


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

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

[Andrew Dul]

On 4/18/2020 9:40 AM, hostmas...@uneedus.com wrote:

I look at it this way:

An ISP with only a /24 of IPv4 space only has 254 addresses to hand 
out to its customers.  If they receive a /40 of IPv6 space, they can 
assign up to 256 /48's to its customers, almost an exact match. 
Someone with so little IPv4 either has few customers or is using CGnat.


Something needs to be done to stop that $250 to $500 increase for 
accepting IPv6 in this population, as the facts seem to show that 
these businesses are simply rejecting the future (IPv6) simply because 
of the current ARIN fee schedule. The provided data clearly show the 
majority are rejecting IPv6, likely because of the fees.  The 
population is so small that if there is a question as to why, why not 
drop them an email and ask?


I would have no problem instead simply giving this population a /36 or 
even a /32 at the same $250 price, simply because I think the goal of 
universal IPv6 is worth it.


I support this /40 policy simply because it addresses the identifed 
issue.


I would also support other ideas, such as going ahead and giving them 
the /36 and waving the price increase.


I also would not have a problem changing the fee schedule to be based 
solely on IPv4, or in the alternative maybe not considering IPv6 
holdings at all in the fee schedule unless they exceed a /32, since a 
/32 is effectively the default for ISP members.


I realize that this would effectively make those with no IPv4 holdings 
fit in most cases into the 3x small bucket.


In the end, if we allow /40's, I have no problem allowing those above 
3X Small to use them, even though they would be able to receive more 
under the fee schedules.  I am no understanding as to why they would 
want a smaller allocation, but who am I to question such a decision of 
others.


How many members of ARIN have no IPv4 holdings, but instead have only 
IPv6? 


There are a number of organizations which only have IPv6.  Likely 
because they are legacy organizations and their IPv4 is held as legacy 
and their IPv6 is held in a different org-id.  Slide 9 & 10 from this 
presentation from the last meeting has some details about the number of 
orgs with various holdings.


https://www.arin.net/vault/participate/meetings/reports/ARIN_44/PDF/MEM/sweeting_rsd.pdf

Hope this helps,

Andrew

___
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: IPv6 Nano-allocations

[Andrew Dul]

When in the application process are the isps informed that their fees will 
increase if they accept the ipv6 block?  Is that in the ipv6 approved email and 
then the tickets are abandoned?

.Andrew

> On Apr 16, 2020, at 4:19 AM, hostmas...@uneedus.com wrote:
> 
> Is that very much because they found out if they accepted the IPv6 space, 
> their fees would double???
> 
> If so, this PROVES the need to adopt this plan.  We should not have things in 
> place that prevent IPv6 adoption.  We have already decided that IPv6 should 
> be cost neutral.  Lets fix this glitch and let these 3x small people have 
> IPv6 without doubling their cost.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
>> On Thu, 16 Apr 2020, John Sweeting wrote:
>> 
>> Yes that is exactly what it means. After approval they decided for whatever 
>> reason they no longer wanted the resource.
>> 
>> Sent from my iPhone
>> 
>>> On Apr 16, 2020, at 1:56 AM, John Santos  wrote:
>>> 
>>> What does "closed with no action" mean?  Does it mean the RSP abandoned 
>>> the request?
>>> 
>>> 
>>>> On 4/15/2020 7:18 PM, John Sweeting wrote:
>>>> Hi Andrew,
>>>> 
>>>> The numbers around this are:
>>>> 
>>>> 320 3x small RSPs
>>>> 30 have applied and been approved for IPv6 of which 26 closed with no 
>>>> action to complete by the requester. The other 4 are currently still open 
>>>> and pending action.
>>>> 
>>>> Thanks,
>>>> John S.
>>>> 
>>>> On 4/15/20, 11:30 AM, "Andrew Dul"  wrote:
>>>> 
>>>>John,
>>>> Could you provide the community with a rough magnitude of this 
>>>> issue?
>>>> Approximately how many of these 3x-small ISP organizations have 
>>>> come to
>>>>ARIN and requested IPv6?  How many accepted the block and how many
>>>>refused because of the fee issue?  How many 3x-small ISP organizations
>>>>does ARIN currently serve.
>>>> Thanks,
>>>>Andrew
>>>> On 4/14/2020 2:29 PM, John Sweeting wrote:
>>>>   > All,
>>>>   >
>>>>   > For anyone interested in the content of the "Policy Experience Report 
>>>> presented by Registration
>>>>   > Services to the AC at its annual workshop in January 2020" referenced 
>>>> in the problem statement you can see that report here:
>>>>   >
>>>>   > 
>>>> https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
>>>>   >
>>>>   > Thank you.
>>>>   >
>>>>   > On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
>>>>  wrote:
>>>>   >
>>>>   > On 19 March 2020, the ARIN Advisory Council (AC) accepted
>>>>   > "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
>>>>   >
>>>>   > Draft Policy ARIN-2020-3 is below and can be found at:
>>>>   >
>>>>   > https://www.arin.net/participate/policy/drafts/2020_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
>>>>   > Policy Analyst
>>>>   > American Registry for Internet Numbers (ARIN)
>>>>   >
>>>>   >
>>>>   >
>>>>   > Draft Policy ARIN-20

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

[Andrew Dul]

John,

Could you provide the community with a rough magnitude of this issue? 

Approximately how many of these 3x-small ISP organizations have come to
ARIN and requested IPv6?  How many accepted the block and how many
refused because of the fee issue?  How many 3x-small ISP organizations
does ARIN currently serve.

Thanks,
Andrew

On 4/14/2020 2:29 PM, John Sweeting wrote:
> All,
>
> For anyone interested in the content of the "Policy Experience Report 
> presented by Registration 
> Services to the AC at its annual workshop in January 2020" referenced in the 
> problem statement you can see that report here:
>
> https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
>
> Thank you.
>
> On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
>  wrote:
>
> On 19 March 2020, the ARIN Advisory Council (AC) accepted 
> "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
> 
> Draft Policy ARIN-2020-3 is below and can be found at:
> 
> https://www.arin.net/participate/policy/drafts/2020_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
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
> 
> Problem Statement:
> 
> ARIN's fee structure provides a graduated system wherein organizations
> pay based on the amount of number resources they consume.
> 
> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), 
> its annual fees will double from $250 to $500/year.
> 
> According to a Policy Experience Report presented by Registration 
> Services to the AC at its annual workshop in January 2020, this 
> represents a disincentive to IPv6 adoption with a substantial fraction 
> of so-situated ISPs saying "no thanks" and abandoning their request for 
> IPv6 number resources when informed of the impact on their annual fees.
> 
> This can be addressed by rewriting subsection 6.5.2(b). Initial 
> Allocation Size to allow allocation of a /40 to only the smallest ISPs 
> upon request, and adding a new clause 6.5.2(g) to cause an automatic 
> upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.
> 
> Reserving /40s only for organizations initially expanding into IPv6 from 
> an initial sliver of IPv4 space will help to narrowly address the 
> problem observed by Registration Services while avoiding unintended 
> consequences by accidentally giving a discount for undersized allocations.
> 
> Policy Statement:
> 
> Replace the current 6.5.2(b) with the following:
> 
> b. In no case shall an LIR receive smaller than a /32 unless they
> specifically request a /36 or /40.
> 
> In order to be eligible for a /40, an ISP must meet the following 
> requirements:
>   * Hold IPv4 direct allocations totaling a /24 or less (to include zero)
>   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
> include zero)
> 
> In no case shall an ISP receive more than a /16 initial allocation.
> 
> Add 6.5.2(g) as follows:
> 
> g. An LIR that requests a smaller /36 or /40 allocation is entitled to 
> expand the allocation to any nibble aligned size up to /32 at any time 
> without renumbering or additional justification.  /40 allocations shall 
> be automatically upgraded to /36 if at any time said LIR's IPv4 direct 
> allocations exceed a /24. Expansions up to and including a /32 are not 
> considered subsequent allocations, however any expansions beyond /32 are 
> considered subsequent allocations and must conform to section 6.5.3. 
> Downgrades of any IPv6 allocation to less than a /36 are not permitted 
> regardless of the ISP's current or former IPv4 number resource holdings.
> 
> Comments:
> 
> The intent of this policy proposal is to make IPv6 adoption at the very 
> bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The 
> author looks forward to a future era wherein IPv6 is the dominant 
> technology and IPv4 is well in decline and 

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

[Andrew Dul]

David, Thanks for your comments.  

On 3/26/2020 4:08 PM, David Farmer wrote:
> I support this policy as written. 
>
> However, I recommend a minor editorial change and a small change to
> the policy;
>
> 1. I would prefer to not use "smaller" or "less" when referring to /24
> or longer prefixes, such use is somewhat ambiguous, this has been
> discussed many times on PPML.
Noted.
>
> 2. I really like the idea of automatically increasing the IPv6
> allocation to /36 when the IPv4 allocation increases beyond /24. How
> about also automatically increasing the IPv6 allocation to /32 when
> the IPv4 allocation increases beyond /22?

The goal of this policy is to create IPv6 allocation sizes such that a
current IPv4 organization which is currently 3X-small can obtain an IPv6
allocation without their fees going up.  Today this issue only occurs
with 3x-small.  If we were to implement this other change I believe this
would cause the text to move beyond the current problem statement. 

I will also like to note, that this issue could also be remedied by the
board adopting a small change to the fee schedule such that the 3x-small
IPv6 holdings do not force a change in category for 3x-small
organizations. This would cause 3x-small organization's fees to be
primarily determined by their IPv4 holdings not their IPv6 holdings.

While the community doesn't have purview over fees we have input into
that process.  If this is something that we would strongly like to
prefer as a solution to this problem.  We can make this as a strong
suggestion to the board for their consideration.

Andrew


>
> Thanks
>
> On Tue, Mar 24, 2020 at 12:22 PM ARIN  > wrote:
>
> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
>
> Problem Statement:
>
> ARIN's fee structure provides a graduated system wherein organizations
> pay based on the amount of number resources they consume.
>
> In the case of the very smallest ISPs, if a 3X-Small ISP (with a
> /24 or
> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a
> /36),
> its annual fees will double from $250 to $500/year.
>
> According to a Policy Experience Report presented by Registration
> Services to the AC at its annual workshop in January 2020, this
> represents a disincentive to IPv6 adoption with a substantial
> fraction
> of so-situated ISPs saying "no thanks" and abandoning their
> request for
> IPv6 number resources when informed of the impact on their annual
> fees.
>
> This can be addressed by rewriting subsection 6.5.2(b). Initial
> Allocation Size to allow allocation of a /40 to only the smallest
> ISPs
> upon request, and adding a new clause 6.5.2(g) to cause an automatic
> upgrade to at least a /36 in the case where the ISP is no longer
> 3X-Small.
>
> Reserving /40s only for organizations initially expanding into
> IPv6 from
> an initial sliver of IPv4 space will help to narrowly address the
> problem observed by Registration Services while avoiding unintended
> consequences by accidentally giving a discount for undersized
> allocations.
>
> Policy Statement:
>
> Replace the current 6.5.2(b) with the following:
>
> b. In no case shall an LIR receive smaller than a /32 unless they
> specifically request a /36 or /40.
>
> In order to be eligible for a /40, an ISP must meet the following
> requirements:
>   * Hold IPv4 direct allocations totaling a /24 or less (to
> include zero)
>   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to
> include zero)
>
> In no case shall an ISP receive more than a /16 initial allocation.
>
> Add 6.5.2(g) as follows:
>
> g. An LIR that requests a smaller /36 or /40 allocation is
> entitled to
> expand the allocation to any nibble aligned size up to /32 at any
> time
> without renumbering or additional justification.  /40 allocations
> shall
> be automatically upgraded to /36 if at any time said LIR's IPv4
> direct
> allocations exceed a /24. Expansions up to and including a /32 are
> not
> considered subsequent allocations, however any expansions beyond
> /32 are
> considered subsequent allocations and must conform to section 6.5.3.
> Downgrades of any IPv6 allocation to less than a /36 are not
> permitted
> regardless of the ISP's current or former IPv4 number resource
> holdings.
>
> Comments:
>
> The intent of this policy proposal is to make IPv6 adoption at the
> very
> bottom end expense-neutral for the ISP and revenue-neutral for
> ARIN. The
> author looks forward to a future era wherein IPv6 is the dominant
> technology and IPv4 is well in decline and considered optional
> leading
> the Community to conclude that sunsetting this policy is prudent
> in the
> interests of avoiding an incentive to request undersized IPv6
>   

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

[Andrew Dul]

I would say as a continuing ARIN member they are responsible for keeping
up their POC and abuse records just like any other member.

Andrew

On 1/28/2020 11:52 AM, Brian Jones wrote:
>
> Question: Does this mean that the entity responsible for the continued
> resource holdings is subject to keeping up the POC and abuse contact
> information for each of the locations or allocation blocks where it
> continues to use ARIN resources? 
>
> —
> Brian Jones
> NI Virginia Tech
> bjo...@vt.edu 
>
>
> On Tue, Jan 28, 2020 at 7:23 AM ARIN  > wrote:
>
> The following has been revised:
>
> * Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
>
> Revised text is below and can be found at:
>
> https://www.arin.net/participate/policy/drafts/2019_12/
>
> 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-12: M Legal Jurisdiction Exclusion
>
> Problem Statement:
>
> Merger and acquisition activity sometimes results in a surviving
> legal
> entity that is not in ARIN service region, but may prefer to continue
> the pre-existing relationship with ARIN.
>
> Example: Imagine a case where a global company has decided to
> discontinue service in the ARIN service region (shuttering ARIN
> region
> offices laying off ARIN region employees, and canceling ARIN region
> customers) and repurpose the network resources and number
> resources in
> the rest of its global footprint. During restructuring the company
> concentrates its holdings in its European subsidiary, and then
> dissolved
> its US legal entity.
>
> Imagine a case where a global company has decided to divest its
> service
> in the ARIN region (selling all ARIN region offices, all ARIN region
> network assets, all ARIN service region customers, all number
> resources
> used in the ARIN (associated with previous noted sale of network and
> customers), but retaining ARIN issued resources in use outside of the
> ARIN service region. During restructuring the company concentrates
> its
> holdings which are not in us in the ARIN service region in its
> European
> subsidiary, and then sells off its US legal entity (including the
> network, customers, addresses in use, etc) dissolved its US legal
> entity.
>
> Policy Statement:
>
> Add the following to section 8.2
>
> Mergers, acquisitions, and reorganization activity resulting in the
> surviving entity ceasing to have a real and substantial connection
> with
> the ARIN region shall be permitted to continue holding any numbering
> resources issued (directly or indirectly) by ARIN prior to the
> merger,
> acquisition or reorganization activity, but shall not qualify for any
> additional numbering resources (directly or indirectly) from ARIN,
> unless and until it once again has a real and substantial connection
> with the ARIN region as required by the Numbering Resource Policy
> Manual.
>
> Timetable for Implementation: Immediate
>
> Anything Else:
>
> This proposal may be overtaken by a more general approach to ARIN
> membership legal jurisdiction exclusion
>
> To clarify scope, a legal entity present within the ARIN service
> region,
> and a current ARIN RSA executed with that entity, is necessary to
> receive allocations or assignments from ARIN. Therefore in the
> scenario
> postulated in the problem statement, the organization would have to
> re-establish itself within the ARIN service region to receive
> additional
> resources from ARIN, while it can continue to hold the allocations or
> assignments made prior to any merger, acquisition, or reorganization
> activity.
>
>
> ___
> 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
> 

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

[Andrew Dul]

Happy New Year everyone...

We had a robust discussion on this list before the New Year, but it was
clear that we don't have consensus on the current draft.  Thus to help
move this draft forward...  I'm proposing a couple of questions to see
if we can find middle ground here to update the text of the draft policy. 

The policy as written today would require organizations who wish to
obtain an IPv4 transfer to complete a limited scope IPv6 deployment.

Do you support any IPv6 requirements on an IPv4 transfer?

Would you support IPv6 requirements for receiving a block via the ARIN
wait-list?

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


Thanks for your comments on this draft,

Andrew


=== 

*Current Policy Statement:*

In section 8.5.2, add the following language to the end of the paragraph
entitled “Operational Use”:

Such operational network must at minimum include an allocation or
assignment by ARIN of IPv6 address space under the same Org ID receiving
the transferred IPv4 space. Such Org must be able to prove this IPv6
space is being routed by using it to communicate with ARIN.

In the event the receiver provides a written statement from its upstream
that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.

===

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

Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2019-3: Update 4.10 – IPv6 Deployment Block

[Andrew Dul]

On 11/6/2019 11:21 AM, John Santos wrote:
> On 11/6/2019 12:57 PM, ARIN wrote:
>
>> This policy attempts to address these issues, by raising the minimum
>> size to a /24 and limits total amount an organization can receive to
>> a /21. It also removes the requirement for return and renumber, since
>> that was primarily added to allow organizations to obtain larger
>> blocks if that was necessary. The policy also clarifies the
>> utilization requirements by placing them directly in this section
>> rather than a reference to the utilization requirements of end users.
>>
>> Policy Statement:
>>
>> Replace current 4.10 with the following updated section
>>
>> 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
>>
>> ARIN shall allocate a contiguous /10 from its last /8 IPv4 allocation
>> from IANA. This IPv4 block will be set aside and dedicated to
>> facilitate IPv6 deployment. Allocations and assignments from this
>> block must be justified by immediate IPv6 deployment requirements.
>> Examples of such needs include: IPv4 addresses for key dual stack DNS
>> servers, and NAT-PT or NAT464 translators. ARIN staff will use their
>> discretion when evaluating justifications.
>>
>> This block will be subject to a minimum and maximum size allocation
>> of /24. ARIN should use sparse allocation when possible within that
>> /10 block.
>
> This contradicts the statement above that the maximum allocation or
> assignment is a /21, not a /24.  Or is it intended that the initial
> allocation or assignment is always a /24, but the recipient can later
> ask for more, up to a /21, with appropriate justification?
>
> Or is it worded that way so that if an applicant comes back for a
> second (or subsequent) allocation/assignment under this section (for a
> second discrete network?) they may receive no more than a /21 in total?
>
> Also, if the allocation or assignment is a /24, no more and no less,
> what is the point of the 2nd sentence that ARIN should use sparse
> allocation?  Is it so applicants taking a second dip will, if
> possible, get a contiguous /24 each time?
>
>
The original intent of this rewrite is that the initial assignment or
allocation will always be a /24.  Any additional assignments will also
be a /24.  An organization could come back every 6 months to get more
addresses up to a /21.

Andrew



___
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-14: No Specified Transfers for 4.1.8.2 Blocks

[Andrew Dul]

Hello,

I have not seen a lot of support for this draft policy and based upon
that feedback from the community I intend to recommend to the full AC at
the next teleconference that this draft be abandoned.  If you feel
differently and would like to support this policy moving forward, please
state your support on the list.

Thank you,
Andrew

On 7/8/2019 10:56 AM, Andrew Dul wrote:
> Hello,
>
> With the ARIN board recently adopting the AC's recommendation to
> re-instate the wait-list policy, we should now reconsider this draft
> policy to the wait-list policy in light of those changes. In the AC's
> recommendation, a 60 month transfer restriction was placed on any
> block received from the wait-list starting with the re-implementation
> of the policy.
>
> Do you feel this 60 month restriction is sufficient?
>
>
> This draft policy calls for prohibition on non M transfers and
> restricts M transfers to the same purpose as requested under the
> wait-list policy.
>
> Would you prefer a complete prohibition on transfer of these blocks? 
> Should an exception & restrictions be allowed for M transfers?
>
>
> Your input here is helpful to help the AC determine if this draft
> policy should be updated to reflect the recently adopted re-instated
> wait-list policy text or if this draft policy should now be abandoned
> given the 60 month restriction in the current wait-list policy.
>
>
> Thanks,
>
> Andrew
>
>
> On 5/21/2019 11:06 AM, ARIN wrote:
>> On 16 May 2019, the ARIN Advisory Council (AC) accepted
>> "ARIN-prop-274: No Specified Transfers for 4.1.8.2 Blocks" as a Draft
>> Policy.
>>
>> Draft Policy ARIN-2019-14 is below and can be found at:
>> https://www.arin.net/participate/policy/drafts/2019_14/
>>
>>
>> Draft Policy ARIN-2019-14: No Specified Transfers for 4.1.8.2 Blocks
>>
>> Problem Statement:
>>
>> The ARIN “Unfulfilled Requests” policy creates an opportunity for an
>> ARIN member to claim need for number resources, wait for those
>> resources to become available via returns or reclamations, acquire
>> them (per 4.1.8.2 of the NRPM), wait a day after the mandatory “hold
>> time”, and then profit from them via a specified transfer transaction.
>>
>> This waiting list policy freely provides number resources, creating
>> an incentive for profit-taking through fraudulent applications or
>> making misrepresentations to registration services.
>>
>> ARIN can avoid this problem by prohibiting non-8.2 transfers for
>> blocks distributed under 4.1.8.2 using language very similar to
>> policy elsewhere in the NRPM.
>>
>> Policy Statement:
>>
>> Add a second paragraph to 4.1.8.2:
>>
>> IP allocations issued through 4.1.8.2 are non-transferable via
>> section 8.3 and section 8.4. In the case of a section 8.2, transfer
>> of the IP assignment must be utilized for the same purpose or needs
>> justified used for the original 4.1.8 application.
>>
>> Comments:
>>
>> Timetable for implementation: Immediate
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.


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

Re: [arin-ppml] Draft Policy ARIN-2019-14: No Specified Transfers for 4.1.8.2 Blocks

[Andrew Dul]

Hello,

With the ARIN board recently adopting the AC's recommendation to 
re-instate the wait-list policy, we should now reconsider this draft 
policy to the wait-list policy in light of those changes. In the AC's 
recommendation, a 60 month transfer restriction was placed on any block 
received from the wait-list starting with the re-implementation of the 
policy.


Do you feel this 60 month restriction is sufficient?


This draft policy calls for prohibition on non M transfers and 
restricts M transfers to the same purpose as requested under the 
wait-list policy.


Would you prefer a complete prohibition on transfer of these blocks?  
Should an exception & restrictions be allowed for M transfers?



Your input here is helpful to help the AC determine if this draft policy 
should be updated to reflect the recently adopted re-instated wait-list 
policy text or if this draft policy should now be abandoned given the 60 
month restriction in the current wait-list policy.



Thanks,

Andrew


On 5/21/2019 11:06 AM, ARIN wrote:
On 16 May 2019, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-274: No Specified Transfers for 4.1.8.2 Blocks" as a Draft 
Policy.


Draft Policy ARIN-2019-14 is below and can be found at:
https://www.arin.net/participate/policy/drafts/2019_14/


Draft Policy ARIN-2019-14: No Specified Transfers for 4.1.8.2 Blocks

Problem Statement:

The ARIN “Unfulfilled Requests” policy creates an opportunity for an 
ARIN member to claim need for number resources, wait for those 
resources to become available via returns or reclamations, acquire 
them (per 4.1.8.2 of the NRPM), wait a day after the mandatory “hold 
time”, and then profit from them via a specified transfer transaction.


This waiting list policy freely provides number resources, creating an 
incentive for profit-taking through fraudulent applications or making 
misrepresentations to registration services.


ARIN can avoid this problem by prohibiting non-8.2 transfers for 
blocks distributed under 4.1.8.2 using language very similar to policy 
elsewhere in the NRPM.


Policy Statement:

Add a second paragraph to 4.1.8.2:

IP allocations issued through 4.1.8.2 are non-transferable via section 
8.3 and section 8.4. In the case of a section 8.2, transfer of the IP 
assignment must be utilized for the same purpose or needs justified 
used for the original 4.1.8 application.


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

[Andrew Dul]

I support the AC's recommendation as written.

While this policy will limit the organizations that are eligible to 
receive a block, I believe it strikes the right balance.  The smaller 
block size (/22) is generally in line with the final block size 
allocations of the other RIRs.


Furthermore, I would ask the the board consider adopting a fee to 
receive any block from the wait-list.  I believe this fee would be 
beneficial for two purposes.  One, it would help ARIN recover the costs 
associated with managing the wait-list and two, the fee would slightly 
close the gap between the the windfall from receiving a wait-list block 
and the market price of receiving a block via transfer.


Andrew

On 6/6/2019 10:29 AM, Owen DeLong wrote:
Yes. I favor the AC’s revised recommendation. The changes address 
certain staff concerns we hadn’t previously considered while 
maintaining a structure which I believe is widely supported within the 
community.


Even if this isn’t the perfect solution, I believe it is a good way 
forward and additional modification should be done through the 
standard policy process.


Owen


On Jun 6, 2019, at 10:20, 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 

Re: [arin-ppml] Draft Policy ARIN-2019-14: No Specified Transfers for 4.1.8.2 Blocks

[Andrew Dul]

As the draft is written, I would assume it applies to all blocks issued
under 4.1.8.2 because the draft policy doesn't state otherwise.  We
certainly could craft the policy to only apply going forward or it could
also be applicable to all wait-list blocks. 

If members of the community have a preference for how this aspect should
be handled that would be a good thing to comment on for this draft.

Thanks,
Andrew

On 5/21/2019 2:14 PM, Kevin Blumberg wrote:
>
> A suggestion would be to put this in its own subsection and reuse the
> text in 4.2.3.8, removing the 36 months and adding
> allocation/assignment. Reuse of language is helpful as the language
> has already been vetted.
>
>  
>
> 4.1.8.3 IP allocations or assignments issued through 4.1.8 are
> non-transferable via section 8.3
> 
>  and
> section 8.4
> .
> In the case of a section 8.2
> 
>  transfer
> the IP allocation or assignment must be utilized for the same purpose
> or needs based justification at a rate consistent with intended use.
>
>  
>
> I assume this is moving forward and doesn’t affect blocks previously
> provided.
>
>  
>
> Thanks,
>
>
> Kevin Blumberg
>
>  
>
>  
>
> *From:*ARIN-PPML  *On Behalf Of *William
> Herrin
> *Sent:* Tuesday, May 21, 2019 4:08 PM
> *To:* ARIN 
> *Cc:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2019-14: No Specified
> Transfers for 4.1.8.2 Blocks
>
>  
>
> On Tue, May 21, 2019 at 11:06 AM ARIN  > wrote:
>
> Draft Policy ARIN-2019-14: No Specified Transfers for 4.1.8.2 Blocks
>
> Policy Statement:
>
> Add a second paragraph to 4.1.8.2 :
>
> IP allocations issued through 4.1.8.2 are non-transferable via
> section
> 8.3 and section 8.4. In the case of a section 8.2, transfer of the IP
> assignment must be utilized for the same purpose or needs
> justified used
> for the original 4.1.8 application.
>
>  
>
> Too weak.
>
>  
>
> "Organizations holding number resources issued through 4.1.8.2 shall
> be eligible to transfer IPv4 addresses to another organization only as
> allowed by section 8.2."
>
> Regards,
>
> Bill Herrin
>
>  
>
>  
>
> -- 
>
> William Herrin
>
> b...@herrin.us 
>
> https://bill.herrin.us/
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.


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

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

[Andrew Dul]

Hello,

I'd like to bring your attention to another issue that may have been
lost in the flurry of other emails.  We are currently in a 14 day
feedback period for the AC's response to the Board's suspension of the
wait-list.   Please note the following updated text for the wait-list. 
Your comments on this updated text are welcome.

Thanks,

Andrew


===

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, for which the organization is qualified,
which in the case of the waiting list shall not be larger than a /22,
and the smallest block size acceptable to the organization. An
organization may not be added to the waiting list if it already holds
IPv4 resources amounting in aggregate to more than a /20 of address
space. Resources received via section 4.1.8 may not be transferred
within 60 months of the issuance date.



 Forwarded Message 
Subject:[arin-ppml] Advisory Council Recommendation Regarding NRPM
4.1.8. Unmet Requests
Date:   Mon, 29 Apr 2019 11:16:31 -0400
From:   ARIN 
To: arin-ppml@arin.net



Subject:

At their 16 January Meeting, the Board of Trustees suspended issuance of
number resources under NRPM section 4.1.8.2. (Fulfilling Unmet Needs),
and referred NRPM section 4.1.8 to the ARIN Advisory Council for their
recommendation.

The Advisory Council has provided its recommendation, and per ARIN's
Policy Development Process, the recommendation is hereby submitted to
the Public Policy Mailing List for a community discussion period of 14
days, to conclude on 13 May.

Once completed, the Board of Trustees will review the AC’s
recommendation and the PPML discussion.

The full text of the Advisory Council's recommendation is below.

Board of Trustees meeting minutes are available at:

https://www.arin.net/about/welcome/board/meetings/2019_0116/

For more details on the Policy Development Process, visit:

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

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



Advisory Council recommendation:

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 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. 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, for which the organization is qualified,
which in the case of the waiting list shall not be larger than a /22,
and the smallest block size acceptable to the organization. An
organization may not be added to the waiting list if it already holds
IPv4 resources amounting in aggregate to more than a /20 of address
space. Resources received via section 4.1.8 may not be transferred
within 60 months of the issuance date.

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. 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.
___
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-2017-12: POC Notification and Validation Upon Reassignment or Reallocation

[Andrew Dul]

You are correct, this policy change only affects detailed-reassignments
and reallocations.  Simple-reassignments do not have POC records
associated with them.

Andrew

On 4/24/2019 10:18 AM, Andrew Bagrin wrote:
> I'm sorry if I missed this somewhere, but this does not affect simple
> reassignment of /29 or smaller, correct?
>
> Thanks,
> Andrew
>
> On Mon, Apr 22, 2019 at 10:58 PM Owen DeLong  > wrote:
>
> Support… Implementation ASAP, please.
>
> Owen
>
>
>> On Apr 22, 2019, at 07:27 , David Farmer > > wrote:
>>
>> There have been relatively few comments on this policy on PPML
>> since the text was revised in late January. Although, it seems to
>> have been well supported at the Barbados meeting. 
>>
>> ARIN 43 transcript;
>> 
>> https://www.arin.net/vault/participate/meetings/reports/ARIN_43/ppm1_transcript.html#anchor_9
>>
>> ARIN 43 Video for presentation;
>> https://www.youtube.com/watch?v=KxfZ128IqMU
>>
>> ARIN 43 Presentation Slide deck;
>> 
>> https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/2017_12_intro.pdf
>> 
>> https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/2017_12.pdf
>>
>> It is therefore particularly important for anyone who objects to
>> this policy or thinks this policy will create issues for their
>> organization to speak up during this clast call period. 
>>
>> Even if you support the policy, comments regarding the proper
>> timeline for implementation are of interest.  How long will your
>> organization need to adapt to these changes? 
>>
>> All comments are appreciated.
>>
>> Thank you.
>>
>> David Farmer
>>
>>
>> On Mon, Apr 15, 2019 at 1:04 PM ARIN > > wrote:
>>
>> The ARIN Advisory Council (AC) met on 10 April 2019 and
>> decided to send
>> the following Recommended Draft Policy to Last Call:
>>
>> ARIN-2017-12: POC Notification and Validation Upon
>> Reassignment or
>> Reallocation
>>
>> Feedback is encouraged during the Last Call period. All
>> comments should
>> be provided to the Public Policy Mailing List. Last Call will
>> expire on
>> 29 April 2019.
>>
>> The Recommended Draft Policy text is below and available at:
>> https://www.arin.net/participate/policy/drafts/
>>
>> The ARIN Policy Development Process is available at:
>> https://www.arin.net/participate/policy/pdp/
>>
>> Regards,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> Recommended Draft Policy ARIN-2017-12: POC Notification and
>> Validation
>> Upon Reassignment or Reallocation
>>
>> AC Assessment of Conformance with the Principles of Internet
>> Number
>> Resource Policy:
>>
>> This recommended draft policy: (1) enables fair and impartial
>> number
>> administration as it ensures that ARIN has the means to
>> communicate with
>> organizations receiving reallocations or detailed
>> reassignments, and
>> does so in a clear, complete, concise and unambiguous manner;
>> (2) is
>> technically sound in that it supports ARIN’s ability to
>> maintain the
>> unique registration of Internet number resources; and (3) has
>> community
>> support.
>>
>> Problem Statement:
>>
>> Some ISPs assign individuals to be POCs for reassigned blocks
>> without
>> consultation of the individual they are inserting into Whois.
>> For
>> example, during the reassignment/reallocation process, some
>> large ISPs
>> automatically create POCs from their customer’s order form.
>> This process
>> is automated for many ISPs and therefore the resulting POCs
>> are not
>> validated prior to being created in the ARIN Whois database.
>> This
>> creates unknowing POCs that have no idea what Whois is or
>> even who ARIN
>> is at the time they receive the annual POC validation email.
>> It can also
>> create multiple POCs per email address causing that same
>> person to
>> receive a multitude of POC Validation emails each year.
>>
>> This policy proposal seeks to prevent the situation where a
>> POC is
>> unwittingly and unintentionally inserted into Whois. Doing so
>> will
>> reduce the significant amount of time that ARIN staff spend
>> fielding
>> phone calls from POCs who have no idea they are in Whois.
>>
>> The proposal will improve the overall POC validation
>> situation, by
>> ensuring that all reallocation or detailed reassignment
>> 

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

[Andrew Dul]

On 4/2/2019 4:17 PM, Jo Rhett wrote:
On Apr 1, 2019, at 4:45 PM, Owen DeLong > wrote:

as it occurs to me that the following dilemma comes into play:

I, as a contractor, often create ORG records for (and at the request 
of) my clients. I’m not their ISP and I’m not creating the records 
without their knowledge or informed consent (which is the real 
problem here). In fact, I only create them when I am in the process 
of preparing an IP and/or ASN request for them.


I agree completely with everything Owen said, as I often work in the 
same capacity.


There also exists situations where a data center (or other 
organizations) which doesn't own or provide IP assists its customers 
with preparation of documents for self-management. Perhaps even 
coarser, there are datacenter utilities and programs that help people 
prepare or fill out forms. This is under the direction or express 
action of the customer, but may be generated programatically.


It's hard to read the current proposal and understand the 
responsibilities in that context. I think we should be friendly to 
automation opportunities for people who only interact with ARIN once 
or twice in their organization's lifetime. (especially in the v6 era)


The staff assessment of this draft policy perhaps helps with the 
understanding of how ARIN staff will implement this policy.  And maybe 
will help illuminate if additional clarity is needed.


===

Draft Policy 2018-05  requires that only an authorized contact, that is 
verified by ARIN, be allowed to create new organization records. The 
request must be submitted directly to ARIN by the verified authorized 
contact and no third-parties shall be allowed to create organization 
records on behalf of the new organization.


===

The use-case of a contractor working for an organization is a valid use 
case that we need to consider in the implementation of this policy.  The 
draft policy states that "authorized contact representing an entity" can 
create org-id records.  This might be the case of an additional step to 
verify that a contractor is authorized to create a record on an 
organizations behalf.  But, I believe the text itself allows for an 
authorized "contact/contractor" to create an org-id for a specified 
organization.


Andrew


___
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-2018-5: Disallow Third-party Organization Record Creation

[Andrew Dul]

The ARIN advisory council will be considering this draft policy at its 
upcoming teleconference later this week.


The AC would appreciate your statement of support (or lack of thereof) 
for this updated draft to help make a determination if this draft policy 
is strongly supported by the community and thus is ready to move toward 
recommended status.


If you do not support this draft, we would appreciate your comments on 
if you support this draft policy change in concept and any text changes 
that you would suggest to improve the draft policy.


Also, if you are a network operator who creates or modifies a 
significant number of reassigned-detailed or reallocation records the AC 
would appreciate your input on if you use automated tools to create 
org-id records and how long it might take for your organization to make 
changes necessary to comply with this number policy change.


Thanks,

Andrew

On 2/4/2019 10:54 AM, ARIN wrote:

The following has been revised:

* Draft Policy ARIN-2018-5: Disallow Third-party Organization Record 
Creation


Revised text is below and can be found at:
https://www.arin.net/policy/proposals/2018_5.html

You are encouraged to discuss all Draft Policies on PPML. The AC will 
evaluate the discussion in order to assess the conformance of this 
draft policy with ARIN's Principles of Internet number resource policy 
as stated in the Policy Development Process (PDP). Specifically, these 
principles are:


* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community





Draft Policy ARIN-2018-5: Disallow Third-party Organization Record 
Creation


Problem Statement:

Since the introduction of simple-reassignment some years ago, it is no 
longer necessary to allow for third-parties (such as upstream ISPs) to 
create organization records for another entity (such as their 
customers).  In particular, many entities find that spurious 
organization records are routinely created in their name, causing both 
confusion and entity + staff time for clean-up.


Therefore, this policy establishes that organization records shall be 
created only by the entity represented by the organization record, and 
should be created only through an explicit request to ARIN.  ISPs 
wishing to reassign space to customers should either ask the customer 
for their ORG-ID or shall use the "simple reassignment" method which 
does not require nor create new organization records.  ISPs wishing to 
reallocate space to customers should ask the customer for their ORG-ID.


Policy Statement:

Add new section(s) into the NRPM:

3.X Directory Service Records

3.X.1 Organization Record Creation

New organization records shall be created upon ARIN receiving a 
request directly from an authorized contact representing an entity 
that ARIN is able to validate.  Organization records shall not be 
created upon the request of third-parties.


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] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

[Andrew Dul]

The draft policy does not specifically state what happens.  I think the
best would be to give an organization currently on the list the option
of adjusting their minimum size to the new maximum, if their current
minimum is less than the new maximum.  We could include this in the
implementation notes or include it in updated draft policy text if desired.

Andrew

On 3/7/2019 9:47 AM, Robert Clarke wrote:
> Forgive me if this has been addressed, but what happens to anyone on
> the waiting list with a /21+ minimum acceptable allocation after this
> proposed draft goes into effect?
>
> Best Regards,
>
> Robert Clarke
> CubeMotion LLC
> rob...@cubemotion.com 
> M: +1 (844) 244-8140 ex. 512
> 300 Lenora Street #454, Seattle, WA, 98121
>
>
> ___
> 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-6: Clarify Reassignment Requirements in 4.2.3.7.1

[Andrew Dul]

The intent of this draft policy is not to make lines 7-12 of the simple 
reassignment optional.  The intent is to clarify to the community that a 
detailed reassignment record is not required for most reassignments.


Andrew

On 1/25/2019 12:00 PM, Roberts, Orin wrote:


Please clarify.

This proposal is making lines _7 to 12_ on the template 
optional/obsolete for all Simple Reassignment SWIPs?


https://www.arin.net/resources/request/reassignments.html

Template: ARIN-REASSIGN-SIMPLE-5.1
**  As of April 2018
**  Detailed instructions are located below the template.
00. API Key:
01. Registration Action (N,M, or R):
02. Network Name:
03. IP Address and Prefix or Range:
04. Origin AS:
05. Private (Yes or No):
06. Customer Name:
07. Customer Address:
07. Customer Address:
08. Customer City:
09. Customer State/Province:
10. Customer Postal Code:
11. Customer Country Code:
12. Public Comments:
END OF TEMPLATE

cid:image001.jpg@01C9B448.7DFDA670



**

*Orin Roberts - JNCIA, CCNA, ITILv3*
*IP PROVISIONING*

*Bell Canada***



*'905.614.9338** | *** **orobe...@bell.ca* 

*From:*ARIN-PPML  *On Behalf Of *Alyssa Moore
*Sent:* January-25-19 2:04 PM
*To:* arin-ppml@arin.net
*Subject:* Re: [arin-ppml] Draft Policy ARIN-2018-6: Clarify 
Reassignment Requirements in 4.2.3.7.1


Hell PPML,

It's been a couple weeks since there's been any action here, but it's 
time to shake off the winter and think about some policy! Woo!


This proposal has to do with clarifying the language and requirements 
around reassignments. Please take a look and let your AC know if you 
think we're on the right track or not.


Cheers,
AM

On Tue, Nov 20, 2018 at 3:55 PM ARIN > wrote:


On 15 November 2018 the ARIN Advisory Council (AC) accepted
"ARIN-prop-258: Clarify Reassignment Requirements in 4.2.3.7.1" as a
Draft Policy.

Draft Policy ARIN-2018-6 is below and can be found at:
https://www.arin.net/policy/proposals/2018_6.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-6: Clarify Reassignment Requirements in
4.2.3.7.1

Problem Statement:

Current NRMP section “Reassignment and Reallocation Information” is
being interpreted by some organizations to require a “detailed
reassignment” for all customers.  Under the current reassignment
schema,
only a “detailed reassignment or reallocation” contains fields for
“organizational information”.

This policy intends to simplify the reassignment requirements by
noting
that only a customer’s name is required.  Thus a “simple
reassignment”
can be used for most reassignments.

Policy Statement:

Replace section 4.2.3.7.1 with the following:

4.2.3.7.1. Reassignment and Reallocation Information

Each IPv4 reassignment or reallocation containing a /29 or more
addresses shall be registered via a directory services system which
meets the standards set forth in section 3.2.

Reassignment registrations must include each customer name, except
where
specifically exempted by this policy.  Reassignment registrations
shall
only include point of contact (POC) information if either: (1)
requested
by the customer; or (2) the reassigned block is intended to be routed
and announced outside of the provider's network.

Reallocation registrations must contain the customer’s
organization name
and appropriate point of contact (POC) information.

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 

Re: [arin-ppml] Board of Trustees Remands Recommended Draft Policy ARIN-2017-12

[Andrew Dul]

I'd like to propose to the community a rewrite of 2017-12 that would
hopefully bring it in line with the Implementation B option of the Staff
Implementation memo.

What do others think of this approach?

Andrew


===

Policy statement:

Insert one new section into NRPM 3:

3.7 POC Validation Upon Reassignment or Reallocation

When an organization submits a valid reallocation or detailed
reassignment request to ARIN, the reallocation or reassignment record
must contain POC objects which are currently valid in the ARIN
database.  If the POC objects are not valid, ARIN shall immediately
reject the reallocation or reassignment request.

If the reassignment or relocation record is inserted into the database,
ARIN will email the POCs associated with the new record notifying them
of the new resource being attached to their POC.

If the reassignment or relocation record fails to be inserted because
the POCs are not currently valid, ARIN should send an email notification
to the associated POCs that a reassignment or reallocation record was
rejected because their POC is not currently valid, and provide a link
for the user to validate their POC.



On 8/27/2018 8:12 AM, John Curran wrote:
> On 16 Aug 2018, at 7:04 PM, ARIN  wrote:
>> On 31 July 2018, the ARIN Board of Trustees remanded Recommended Draft 
>> Policy ARIN-2017-12: Require New POC Validation Upon Reassignment to the 
>> Advisory Council, noting:
>>
>> "The ARIN Board of Trustees remands ARIN Recommended Draft Policy 2017-12: 
>> Require New POC Validation Upon Reassignment to the ARIN Advisory Council. 
>> Noting the complexity of the policy, the Board wants a more complete policy 
>> assessment of technical soundness, and recommends interviews by the Advisory 
>> Council with ISPs who make numerous delegation requests including those with 
>> IP management platforms, if such interviews have not been already conducted."
>>
>> The Advisory Council is considering the remand of the Recommended Draft 
>> Policy and appropriate next steps.
>>
>> Board of Trustees Meeting Minutes are available at:
>>
>> https://www.arin.net/about_us/bot/index.html
>>
>> Draft Policy and Policy Proposal texts are available at:
>>
>> https://www.arin.net/policy/proposals/index.html
>>
>> The ARIN Policy Development Process (PDP) can be found at:
>>
>> https://www.arin.net/policy/pdp.html
> Note also that the ARIN Board of Trustees reviewed the AC recommendation as 
> well as a Staff Implementation Assessment memo when considering disposition 
> of Recommended Draft Policy ARIN-2017-12.   A copy of that Staff 
> Implementation Assessment memo is attached as background. 
>
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>
> ___
> 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-2 :Clarification to ISP Initial Allocation and Permit Renumbering (Language improvement)

[Andrew Dul]

The AC has recently been discussing this draft policy and noted that we 
have not heard from the community since this new text has been posted.  
We would like to hear from you on if we should move this policy to 
recommended.



I believe the new text fixes the discrepancy, for initial ISP 
allocations, which depends on if the organization initially applies 
under section4 or section8.  This policy fixes this issue in section4 by 
requiring the same documentation (as required under the section8 
transfer policy) for a new ISP requesting a block larger than a /24.


I support this draft policy.


Thanks,

Andrew


On 6/23/2018 1:18 PM, Kerrie Vassall-Richards wrote:


 1. *Clarification to ISP initial allocation and permit renumbering*
 2. Proposal Originator
  * name: Jason Schiller
  * email: jschil...@google.com 
  * telephone: 202-258-8863
  * organization: Google LLC
 3. Date: 02/01/2017
 4. *Problem Statement:*

As discussed in more detail in ARIN-2017-9 and noted in the ARIN 40 
Policy Experience Report, the criteria to qualify for an initial block 
of address space in 4.2.2 and 8.5.4 are seeming at odds with each 
other. At ARIN 41 the community seemed to prefer the approach 
contained in this policy over the approach in ARIN-2017-9, which was 
subsequently abandoned.


Moreover, as the NRPM (2018-1) currently sits, 4.2.2 appears to state 
that an initial allocation of up to a /21 could be granted without any 
more justification than needed to qualify for a /24. Therefore, 4.2.2 
should be modified, allowing an initial allocation of only a /24 
without any additional justification and allowing an initial 
allocation of up to a /21 when justified by a 24-month allocation plan.


*Policy Statement:*

Replace the current 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.


All ISP organizations without direct allocations, direct assignments, 
re-allocations or reassignments automatically qualify for a /24. These 
organizations are exempt from requirements of showing the efficient 
utilization of previously held IPv4 space. These organizations may 
qualify for a larger than a /24 by documenting how the requested 
allocation will be utilized within the request size specified in 4.2.4.3


ISPs holding re-allocations and/or reassignments must show the 
efficient utilization of their resources consistent with the 
requirements in sections 4.2.3 and 4.2.4


*Comments:*

The timetable for Implementation: Immediate

*Anything Else:*

This is an attempt to clarify the changes that came about from 2016-4.
It also aligns section 4.2 with current transfer policy.
It also re-established the understanding that ISP can renumber and 
return, but putting the last section 4.2.2.1.4 into the ISP additional 
requests section. This text is slightly modified to include returns to 
ARIN in addition to returns to the upstream.





___
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 contacti...@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

[Andrew Dul]

I support this policy to remove this reallocation requirement from the NRPM.  

Andrew

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

[Andrew Dul]

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 idea that providing hotspot, guest access, or
> other such temporary access does not necessitate the making of
> re-assignments from a policy perspective.  Furthermore, such uses are
> not in conflict with the conditions of an assignment (made by ARIN) or
> re-assignment (made by an ISP or LIR). Also, If the details of RFC8273
> need to be mentioned at all, they should be someplace in section 6,
> not in section 2, the definitions of assign, allocate, re-assign and
> re-allocate should remain agnostic about IP version.
>
> Thanks.    
>
> On Mon, Apr 23, 2018 at 2:22 PM, ARIN  > wrote:
>
> On 18 April 2018 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-254: Clarification on IPv6 Sub-Assignments" as a Draft
> Policy.
>
> Draft Policy ARIN-2018-4 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 a practice very
> common in IPv4 which is replicated and even amplified in IPv6: the
> use of IP addresses for point-to-point links or VPNs.
>
> In the case of IPv6, instead of unique addresses, the use of
> unique prefixes (/64) is increasingly common.
>
> Likewise, the policy failed to 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.
>
> Finally, 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.
>
> 5.    Policy Statement
>
> Actual Text
>
> •    Assign - To assign means to delegate address space to an ISP
> or end-user, for specific use within the Internet infrastructure
> they 

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

[Andrew Dul]

Notes inline

On 2/12/2018 10:31 AM, David Farmer wrote:
> I need more input from the community on this one.  Unless you are one
> of the two people who has responded already, please take time to
> respond to the following questions.
>
> Thank you.
>
> On Wed, Jan 31, 2018 at 3:18 PM, David Farmer  > wrote:
>
> There seems to be a bit of controversy on the direction to take
> this policy.  Therefore as the shepherd, it would be helpful to
> hear from additional community members regarding this policy. 
>
> Do you support or oppose the policy as written?
>
Oppose
>
>
> Do you think the inconsistency described in the Problem Statement
> should be corrected?
>
No
>
> If yes, should it be corrected by revising by section 8.5.4 to be
> consistent with section 4.2.2, as proposed by the current text?
>
> Or, as an alternative by revising section 4.2.2 to be consistent
> with section 8.5.4?
>
> Are there other alternatives to correct the inconsistency to be
> considered?
>      
> Other suggestions or comments?
>

I authored this proposal to bring up the issue as noted in the policy
experience report at the last meeting.   While I initially believed this
was an inconsistency that should be corrected, I no longer feel this is
the case after weighing the discussion by other community members.   I
believe that the current transfer policy requirements for an initial
block larger than a /24 as found in 8.5.5 are simple and can be easily
accomplished by an organization which desires to transfer a block larger
than a /24.  Adding additional complexity to the transfer policy is not
desired to correct a small inconsistency with the largely obsolete
section 4 allocation policy.

I do however believe a discussion should be held at the next public
policy meeting and if a solid direction cannot be found on this issue,
the AC should abandon this draft.

Andrew

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

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

[Andrew Dul]

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 <andrew@quark.net
>> <mailto:andrew@quark.net>> wrote:
>>
>>> It sounds like our recollections of what we intended for ISP initial
>>> allocations have diverged. I will admit when I drafted the problem
>>> statement I did not go back through email to see if there was
>>> anything about this issue.
>>>
>>> Assuming we harmonize the problem statement, would you prefer the
>>> /24 as initial no questions asked size or a /21?
>>>
>>> What do others prefer?
>>>
>>> .Andrew
>>>
>>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand <scottleibr...@gmail.com
>>> <mailto:scottleibr...@gmail.com>> 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 requested IPv4 block
>>>> size within 24 months. An officer of the organization shall attest
>>>> to the documentation provided to ARIN."
>>>>
>>>> The intention was that any ISP needing a /21 would need to "provide
>>>> documentation to ARIN which details the use of at least 50% of the
>>>> requested IPv4 block size within 24 months", with officer
>>>> attestation to same.
>>>>
>>>> If that policy is deemed insufficient, and we believe it's better
>>>> to allow transfers of up to /21 without providing documentation to
>>>> ARIN and officer attestation of such, then this proposal would need
>>>> to be re-written with a new problem statement justifying that.
>>>>
>>>> -Scott
>>>>
>>>> On Tue, Nov 21, 2017 at 2:40 PM,

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

[Andrew Dul]

I would agree there is nothing special about /21, that is just where we
ended up at exhaustion. 

It is possible this draft policy doesn't do what the community wants us
to do.  I wrote this draft as a followup to the policy experience report
to continue the conversation about the issue and to correct the
inconsistency.  (Normally, I think of inconsistencies as a "bad" thing
in policy) 

Perhaps what we really do want is a more strict interpretation of the
new section 8 transfer policy?  If so we need a way to signal that to
staff.  I'd think that could happen here on this list or at a meeting
and thus no policy change is needed. 

Andrew

On 12/4/2017 2:47 PM, David Huberman wrote:
> Andrew,
>
> It’s unclear to me that /21 is the correct boundary, especially (as
> Scott Leibrand asked for) absent statistics from the staff (if any
> such stats make sense).  With section 8 policy now wholly separated
> from section 4 policy, I sort of think that it’s the staff who should
> change their practices, and follow section 8 policy as written.  
>
> Further to your problem statement, ISPs should NOT be applying under
> section 4 anymore. We know, however, from staff reports at the recent
> ARIN meeting that they still are applying.  That’s a definite problem,
> but it feels to me to be a different problem than what you are
> tackling in this draft policy proposal. 
>
> Happy to hear and be swayed by data or other arguments.
>
> David 
>
> Sent from my iPhone
>
> On Dec 4, 2017, at 4:30 PM, Andrew Dul <andrew@quark.net
> <mailto:andrew@quark.net>> wrote:
>
>> Scott,  how would you feel about this proposed updated problem
>> statement which focuses on the current issue rather than the past.
>>
>> Andrew
>>
>> *Problem Statement: *
>>
>> It was noted at the ARIN 40 Policy Experience Report, that there is
>> an inconsistency in the initial block size for ISPs. Section 4.2.2
>> notes that the initial ISP block size should be /21 whereas the
>> initial block size in 8.5.4 is noted as "minimum transfer size" which
>> is effectively a /24. This causes ISP organizations to be approved
>> for different initial block size depending on if they first apply
>> apply for a transfer directly under section 8 or if they apply for a
>> block under section 4.  This policy is intended to clarify this
>> issue, by setting a consistent ISP initial IPv4 block size. It was
>> noted that ARIN staff current operational practice is to allow all
>> ISPs an initial /21 for Section 8 transfers.
>>
>>
>>
>> On 11/21/2017 9:19 PM, Scott Leibrand wrote:
>>> I’d be ok with a /21, but there’s nothing magical about that size in
>>> a post-exhaustion world. I’d rather base a loosening on actual
>>> transfer statistics, and consider doing so for both allocations and
>>> assignments. 
>>>
>>> Scott
>>>
>>> On Nov 21, 2017, at 7:28 PM, Andrew Dul <andrew@quark.net
>>> <mailto:andrew@quark.net>> wrote:
>>>
>>>> It sounds like our recollections of what we intended for ISP
>>>> initial allocations have diverged. I will admit when I drafted the
>>>> problem statement I did not go back through email to see if there
>>>> was anything about this issue.
>>>>
>>>> Assuming we harmonize the problem statement, would you prefer the
>>>> /24 as initial no questions asked size or a /21?
>>>>
>>>> What do others prefer?
>>>>
>>>> .Andrew
>>>>
>>>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand
>>>> <scottleibr...@gmail.com <mailto:scottleibr...@gmail.com>> 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 requested IPv4 block
>>>>> size within 24 months. An officer of the organization shall attest
>>>>> to the documentation provided to ARIN."
>>>>>
>>>&g

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

[Andrew Dul]

Scott,  how would you feel about this proposed updated problem statement
which focuses on the current issue rather than the past.

Andrew

*Problem Statement: *

It was noted at the ARIN 40 Policy Experience Report, that there is an
inconsistency in the initial block size for ISPs. Section 4.2.2 notes
that the initial ISP block size should be /21 whereas the initial block
size in 8.5.4 is noted as "minimum transfer size" which is effectively a
/24. This causes ISP organizations to be approved for different initial
block size depending on if they first apply apply for a transfer
directly under section 8 or if they apply for a block under section 4. 
This policy is intended to clarify this issue, by setting a consistent
ISP initial IPv4 block size. It was noted that ARIN staff current
operational practice is to allow all ISPs an initial /21 for Section 8
transfers.



On 11/21/2017 9:19 PM, Scott Leibrand wrote:
> I’d be ok with a /21, but there’s nothing magical about that size in a
> post-exhaustion world. I’d rather base a loosening on actual transfer
> statistics, and consider doing so for both allocations and assignments. 
>
> Scott
>
> On Nov 21, 2017, at 7:28 PM, Andrew Dul <andrew@quark.net
> <mailto:andrew@quark.net>> wrote:
>
>> It sounds like our recollections of what we intended for ISP initial
>> allocations have diverged. I will admit when I drafted the problem
>> statement I did not go back through email to see if there was
>> anything about this issue.
>>
>> Assuming we harmonize the problem statement, would you prefer the /24
>> as initial no questions asked size or a /21?
>>
>> What do others prefer?
>>
>> .Andrew
>>
>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand <scottleibr...@gmail.com
>> <mailto:scottleibr...@gmail.com>> 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 requested IPv4 block
>>> size within 24 months. An officer of the organization shall attest
>>> to the documentation provided to ARIN."
>>>
>>> The intention was that any ISP needing a /21 would need to "provide
>>> documentation to ARIN which details the use of at least 50% of the
>>> requested IPv4 block size within 24 months", with officer
>>> attestation to same.
>>>
>>> If that policy is deemed insufficient, and we believe it's better to
>>> allow transfers of up to /21 without providing documentation to ARIN
>>> and officer attestation of such, then this proposal would need to be
>>> re-written with a new problem statement justifying that.
>>>
>>> -Scott
>>>
>>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN <i...@arin.net
>>> <mailto:i...@arin.net>> wrote:
>>>
>>> On 16 November 2017, the ARIN Advisory Council (AC) advanced
>>> "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP
>>> Transfers" to Draft Policy status.
>>>
>>> Draft Policy ARIN-2017-9 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2017_9.html
>>> <https://www.arin.net/policy/proposals/2017_9.html>
>>>
>>> You are encouraged to discuss all Draft Policies on PPML. The AC
>>> will evaluate the discussion in order to assess the conformance
>>> of this draft policy with ARIN's Principles of Internet number
>>> resource policy as stated in the Policy Development Process
>>> (PDP). Specifically, these principles are:
>>>
>>> * Enabling Fair and Impartial Number Resource Administration
>>> * Technically Sound
>>> * Supported by the Community
>>>
>>> The PDP can be found at:
>>> https://www.arin.net/policy/pdp.html
>>> <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>

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

[Andrew Dul]

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 requested IPv4 block size within 24 months. An officer of 
> the organization shall attest to the documentation provided to ARIN."
> 
> The intention was that any ISP needing a /21 would need to "provide 
> documentation to ARIN which details the use of at least 50% of the requested 
> IPv4 block size within 24 months", with officer attestation to same.
> 
> If that policy is deemed insufficient, and we believe it's better to allow 
> transfers of up to /21 without providing documentation to ARIN and officer 
> attestation of such, then this proposal would need to be re-written with a 
> new problem statement justifying that.
> 
> -Scott
> 
>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN  wrote:
>> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: 
>> Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy 
>> status.
>> 
>> Draft Policy ARIN-2017-9 is below and can be found at:
>> https://www.arin.net/policy/proposals/2017_9.html
>> 
>> You are encouraged to discuss all Draft Policies on PPML. The AC will 
>> evaluate the discussion in order to assess the conformance of this draft 
>> policy with ARIN's Principles of Internet number resource policy as stated 
>> in the Policy Development Process (PDP). Specifically, these principles are:
>> 
>> * Enabling Fair and Impartial Number Resource Administration
>> * Technically Sound
>> * Supported by the Community
>> 
>> The PDP can be found at:
>> https://www.arin.net/policy/pdp.html
>> 
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>> 
>> Regards,
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> 
>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP 
>> Transfers
>> 
>> Problem Statement:
>> 
>> It was noted at the ARIN 40 Policy Experience Report, that there is an 
>> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that 
>> the initial ISP block size should be /21 whereas the initial block size in 
>> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The 
>> intent of the new 8.5.4 was to match the previous policy. This policy is 
>> intended to clarify this issue. It was noted that ARIN staff current 
>> operational practice is to allow ISPs an initial /21 for Section 8 transfers.
>> 
>> Policy statement:
>> 
>> Add the following to 8.5.4
>> 
>> ISP organizations without direct assignments or allocations from ARIN 
>> qualify for an initial allocation of up to a /21.
>> 
>> Comments:
>> 
>> a. Timetable for implementation: Immediate
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
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-8: Amend the Definition of Community Network

[Andrew Dul]

The current text uses the terms "volunteer group, not-for-profit,
non-profit, charitable organization, or educational institution"

My reading of this is that accreditation isn't a requirement.  The text
could be rewritten to remove educational institutions, but some of the
community networks one might imagine are educational organizations
(which are government entities, not necessarily registered/chartered as
non-profit organization)

Andrew

On 9/20/2017 12:54 PM, Whitestone IT wrote:
>
>
> On Wed, Sep 20, 2017 at 9:21 AM, Kevin Blumberg  > wrote:
>
> Andrew,
>
> 3) Why is the scope limited to post-secondary institution when
> many smaller communities would not have that? Could accredited
> educational institution be used instead?
>
>
> Kevin ,
>
> There are educational institutions that would perhaps qualify as a
> volunteer or non-profit that would not qualify as an accredited
> institution — accreditation is largely outside the reach of
> organizations that I believe this policy is targeting.
>
> Is it necessary to limit to accredited educational institutions? Is it
> possible to have a for-profit educational institution that would
> otherwise qualify for a community network designation?
>
> Does the policy need to reference education at all?
>
> -- 
> Jeremy Austin
> Whitestone, Alaska


___
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-8: Amend the Definition of Community Network

[Andrew Dul]

On 9/20/2017 11:01 AM, Kevin Blumberg wrote:
>
>
> I am opposed to the policy if it includes “or other Information
Technology services”. That would basically be any defined organization
that has a website.

Do you have a suggestion of what might be more appropriate wording?  We
were trying to suggest that a community network might provide more than
basic connectivity. 

On 9/20/2017 10:21 AM, Kevin Blumberg wrote:
> Andrew,
>
> Is this the current text of the policy?
>
> The text on 2017-8 on the website does not match. The text below includes " 
> or other Information Technology services" which does not appear on the 
> website (https://www.arin.net/policy/proposals/2017_8.html)
>
> Can you please confirm which is the correct version, I have written my 
> repsonses based on the website.
>
> 1) Can a "Volunteer Group" sign the RSA? 
I'll let ARIN staff answer this part.
> 2) Is charitable organization a synonym or fall under the umbrella of 
> non-profit?
My understanding is that this was intended as a synonym, a list of
descriptors that could be used to define a community network.
> 3) Why is the scope limited to post-secondary institution when many smaller 
> communities would not have that? Could accredited educational institution be 
> used instead?
The text has been updated to "educational institution"
> 4) I agree with Chris W. that "play a large role" is very ambigous.

Do you have a suggestion of text that might be more descriptive?  For
example would a percentage of revenue / wages ratio be applicable?  
That was an idea, but I'm not sure one could easily come up with a ratio
that works.

> 5) The last sentence should be reworded completely. Critical functions may be 
> handled by paid staff, implies that volunteers shouldn't handle Critical 
> functions or that paid staff shouldn't handle menial work?

Should we substitute "Critical" with "Some"?

>
>
>
>
> -Original Message-
> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of Andrew Dul
> Sent: Tuesday, September 19, 2017 11:21 AM
> To: arin-ppml@arin.net
> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the 
> Definition of Community Network
>
> Hello all,
>
> We will be discussing this draft proposal at the upcoming ARIN meeting in San 
> Jose.  If you have comments on the updated draft posted below, we'd certainly 
> like to hear from you so we can help shape the conversation in person. 
>
> We have seen some support for this updated draft, but not a lot. 
> Furthermore, have we addressed all of your concerns which you might have 
> noted earlier on the 1st version of the policy text.
>
> Thanks,
> Andrew
>
> On 8/24/2017 8:22 AM, ARIN wrote:
>>
>> 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 
>> educational institution for the purpose of providing free or low-cost 
>> connectivity, or other Information Technology services to persons or 
>> entities within their community. 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

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

[Andrew Dul]

Hello all,

We will be discussing this draft proposal at the upcoming ARIN meeting
in San Jose.  If you have comments on the updated draft posted below,
we'd certainly like to hear from you so we can help shape the
conversation in person. 

We have seen some support for this updated draft, but not a lot. 
Furthermore, have we addressed all of your concerns which you might have
noted earlier on the 1st version of the policy text.

Thanks,
Andrew

On 8/24/2017 8:22 AM, ARIN wrote:
>
>
> 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
> educational institution for the purpose of providing free or low-cost
> connectivity, or other Information Technology services to persons or
> entities within their community. 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.

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

[Andrew Dul]

Chris, I'd agree that the wording around the requirements that the organization 
have volunteers fulfill a "large" or "predominant" role could be an area of 
improvement in the draft text. 

Do others feel that this part of the definition could be improved too?  If so 
what requirements were would you like to see in the policy language.  

Andrew


> On Aug 23, 2017, at 11:43 AM, Chris Woodfield  wrote:
> 
> 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. 

___
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-7: Retire Obsolete Section 4 From the NRPM

[Andrew Dul]

If there is general community support for pruning back section 4 now
that run-out has happened and section 8 contains the transfer
requirements.  I can pull out my previous drafts and revise and present
those as alternatives to this specific draft text.

Andrew

On 7/17/2017 12:32 PM, Chris Woodfield 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).
>
> 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 

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

[Andrew Dul]

The policy shepherds have seen limited support for this draft and noted this at 
its last full AC meeting.  

Furthermore, we believe that through the discussion of this draft this policy 
change may not be necessary as ARIN's operational practice already permits 
organizations to use a data based projection from previous allocations or 
assignments as documentation for a transfer.  

If you believe the AC should continue to work on this draft, please post a 
statement of support and suggestions of text updates (e.g. Draft text which 
would explicitly state the current operational practice in policy) which you 
believe will garner additional support from the community for this draft.  

In the absence of additional support and/or discussion of this draft the 
shepherds of the policy intended to abandon this draft at their next regular AC 
meeting.

Andrew

> On May 9, 2017, at 7:15 AM, Jason Schiller  wrote:
> 
> John,
> 
> Thank you for the statement.  This makes me feel much more comfortable.
> 
> I wish such text was clearly spelled out in the policy 
> (as I think that is good for the community), but I will happily 
> take such text as part of the unwritten rules of the NRPM.
> 
> Would you say the policy proposal as written is an operation non-op 
> for ARIN staff?
> 
> ___Jason
> 
>
> 
> 
>> On Mon, May 8, 2017 at 5:56 PM, John Curran  wrote:
>> On 8 May 2017, at 12:42 PM, Jason Schiller  wrote:
>> >
>> > John,
>> >
>> > In a word no.
>> >
>> > One could imagine a justification that says something like:
>> > - on 12/05 we got a /16
>> >-- (assume we demonstrated efficient utilization of currently
>> > held space at this time)
>> > - on 05/05 we demonstrated efficient use of the this space
>> >--  (assume efficient utilization of the new /16 is justifiable)
>> >--  (assume efficient utilization of previous held space is justifiable)
>> > - at current consumption rate, a /14 represents a two year supply
>> > - we anticipate that our product will continue growing for the for 
>> > see-able future
>> >
>> > Can we have a /14 please?
>> > ---
>> >
>> > Technically the request above makes no prediction about the future.
>> 
>> Jason -
>> 
>> Regardless of whether you call it a prediction or not, your extension of 
>> your consumption rate
>> to establish your 'two year supply’ meets NRPM 8.5.5’s requirement for 
>> “documentation to
>> ARIN which details the use of at least 50% of the requested IPv4 block size 
>> within 24 months.”
>> 
>> This aligns with the clear policy intent of transfer policy as adopted by 
>> the community; so long
>> as an officer of the organization attests to the documentation, such 
>> requests will be approved.
>> 
>> Thanks,
>> /John
>> 
>> John Curran
>> President and CEO
>> ARIN
>> 
> 
> 
> 
> -- 
> ___
> Jason Schiller|NetOps|jschil...@google.com|571-266-0006
> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Andrew Dul]

There has been some good discussion about this draft. 

At this time, it seems like perhaps there is disagreement within the
community on the purpose and use of reassignment records.  As we have
gone past IPv4 run-out, perhaps now is the time to consider if
reassignment records provide the same level of value to the Internet
community that they used to provide.  Doing reassignments was one of the
primary ways that a service provider showed utilization to ARIN.  This
could also be done by having an organization share these records
directly with ARIN during a resource request.

I'd like to throw out a few open ended questions that perhaps will guide
the AC as it considers this draft:

1. Do you think reassignment records provide value to the Internet
community from an operational perspective?  Do they provide the same
value if they are not accurate?  At what point does the "record set" as
a whole become invaluable because the data in the records isn't
representative of current reassignments?

2. Who do you think should be responsible for ensuring that resource
records are accurate?  The organization doing the reassignment?  ARIN? 
Someone else?

3. Given we are past IPv4 run-out, do reassignment records provide the
same value to ARIN for the purposes of determining utilization?  Should
other methods be used to determine utilization going forward?

4. Would you support the concept of removing reassignment records for
which a POC has not been validated after a certain period of time?  1
year?  2 years?  x years?

5. Would you support the idea that a new reassignment could not be added
to the database without the approval of the POC who is receiving the
resource by reassignment?

Thanks for your input

Andrew



On 12/20/2016 10:09 AM, ARIN wrote:
>
>
> ##
>
> 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 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 2016-7 -- Integrate community networks into Existing ISP Policy

[Andrew Dul]

It would be especially helpful for the AC if those who operate community
networks could review the proposed draft policy and see if the problem
statement highlights an issue for operators and if the proposed text
solves this problem.

Thanks,
Andrew



On 12/15/2016 3:30 PM, Kevin Blumberg wrote:
> Owen,
>
> As the author of 2016-7 I disagree. 
>
> The change in 2016-6 had no meaningful impact to the usefulness of Community
> Networks. T
>
> The purpose of 2016-7 was to significantly reduce the red tape requirements
> with Community Networks. 
>
> I believe that without this kind of policy Community Network's will never
> get used given the onerous requirements.
>
> Thanks,
>
> Kevin Blumberg
>
>
>
>
>
>
>
>
>
>
> -Original Message-
> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of Owen DeLong
> Sent: Thursday, December 15, 2016 4:19 PM
> To: ARIN-PPML List 
> Subject: [arin-ppml] Draft Policy 2016-7 -- Integrate community networks
> into Existing ISP Policy
>
> I believe that this proposal no longer has relevance given the advancement
> of 2016-6 and its rewrite of the community networks policy to the board.
>
> If anyone feels that the AC should not abandon this proposal at their
> January meeting, please speak up.
>
> Owen
>
> ___
> 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] Upcoming Public Policy Discussions

[Andrew Dul]

With my community member and author hats on. And in attempt to start this 
conversation before the formal meeting starts on Thursday. 

> On Oct 15, 2016, at 22:16, Alexander, Daniel  
> wrote:
> 
> 
> 
> Related proposals:
> 
> ARIN 2015-7 Simplified Requirements for Demonstrated Need for IPv4 Transfers
> ARIN 2016-3 Alternative Simplified Criteria for Justifying Small IPv4 
> Transfers
> ARIN 2016-4 Transfers for New Entrants
> ARIN 2016-5 Post IPv4 Free Pool Depletion Transfer Policy
> 
> Needed feedback:
> 
> - Is it useful to break the dependency between section 4 and section 8?

Yes, I believe that the rules that were developed for managing the free pool 
are not as applicable when IPv4 number resources are being transferred in the 
marketplace. Simplifying the transfer requirements by breaking the linkage to 
section 4, I think is the best path forward. 

> - Is it useful to simplify the transfer requirements?

Yes, I believe simpler rules would benefit the community by providing 
additional clarity on transfers and also can provide better predictability for 
organizations which decide to purchase IPv4 number rights. 

> - Are the needs requirements in any of the proposals too lax, or too 
> restrictive?
> - Do people prefer one approach over another? Which ones?

As the author of 2016-5, I believe this policy provides the best path forward. 

I also support the ideas in 2015-7, but I believe further work would still be 
needed if this policy was the only change. 

I don't support 2016-3 as this policy does not deal with the clarity needed for 
the largest transfers. 

2016-4 is complementary and overlapping change to 2016-5 and thus I support 
that change, although I believe the larger change of 2016-5 is preferable. 

Andrew

> 
___
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-6: Eliminate HD-Ratio from NRPM

[Andrew Dul]

I support this policy to cleanup the IPv6 policy and remove references
to the HD-ratio which is no longer used in this region to assign or
allocate IPv6 addresses.

Andrew

On 7/26/2016 6:21 AM, ARIN wrote:
>
>
> ##
>
> Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM
>
> Date: 26 July 2016
>
> Problem Statement:
>
> The HD-Ratio has become an anachronism in the NRPM and some of the
> vestigial references to it create confusion about recommended prefix
> sizes for IPv6 resulting in a belief in the community that ARIN
> endorses the idea of /56s as a unit of measure in IPv6 assignments.
> While there are members of the community that believe a /56 is a
> reasonable choice, ARIN policy has always allowed and still supports
> /48 prefixes for any and all end-sites without need for further
> justification. More restrictive choices are still permitted under
> policy as well. This proposal does not change that, but it attempts to
> eliminate some possible confusion.
>
> The last remaining vestigial references to HD-Ratio are contained in
> the community networks policy (Section 6.5.9). This policy seeks to
> replace 6.5.9 with new text incorporating end user policy by reference
> (roughly equivalent to the original intent of 6.5.9 prior to the more
> recent changes to end-user policy). While this contains a substantial
> rewrite to the Community Networks policy, it will not have any
> negative impact on community networks. It may increase the amount of
> IPv6 space a community network could receive due to the change from
> HD-Ratio, but not more than any other similar sized end-user would
> receive under existing policy.
>
> Policy statement:
>
> Replace section 6.5.9 in its entirety as follows:
>
> 6.5.9 Community Network Assignments
>
> While community networks would normally be considered to be ISP type
> organizations under existing ARIN criteria, they tend to operate on
> much tighter budgets and often depend on volunteer labor. As a result,
> they tend to be much smaller and more communal in their organization
> rather than provider/customer relationships of commercial ISPs. This
> section seeks to provide policy that is more friendly to those
> environments by allowing them to use end-user criteria. 6.5.9.1
> Qualification Criteria
>
> To qualify under this section, a community network must demonstrate to
> ARIN’s satisfaction that it meets the definition of a community
> network under section 2.11 of the NRPM. 6.5.9.2 Receiving Resources
>
> Once qualified under this section, a community network shall be
> treated as an end-user assignment for all ARIN purposes (both policy
> and fee structure) unless or until the board adopts a specific more
> favorable fee structure for community networks.
>
> Community networks shall be eligible under this section only for IPv6
> resources and the application process and use of those resources shall
> be governed by the existing end-user policy contained in section 6.5.8
> et. seq.
>
> Community networks seeking other resources shall remain subject to the
> policies governing those resources independent of their election to
> use this policy for IPv6 resources.
>
> Delete section 2.8 — This section is non-operative and conflicts with
> the definitions of utilization contained in current policies.
>
> Delete section 2.9 — This section is no longer operative.
>
> Delete section 6.7 — This section is no longer applicable.
>
> Comments:
>
> Timetable for implementation: Immediate
>
> Anything else
>
> Originally, I thought this would be an editorial change as the
> HD-Ratio has been unused for several years.
>
> However, further research revealed that it is still referenced in the
> Community Networks policy which has also gone unused since its
> inception. As a result, I am going to attempt to simultaneously
> simplify the Community Networks policy while preserving its intent and
> eliminate the HD-Ratio from the NRPM.
>
> I realize that fees are out of scope for policy, however, in this
> case, we are not setting fees. We are addressing in policy which fee
> structure the given policy should operate under in a manner which does
> not constrain board action on actual fees.
>
> This is an attempt to preserve the original intent of the Community
> networks policy in a way that may make it less vestigial.
>
> Alternatively, we could simply delete Section 6.5.9 if that is
> preferred. The primary goal here is to get rid of vestigial reference
> to HD-Ratio rather than to get wrapped around the axle on community
> networks.
> ___
> 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 

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

[Andrew Dul]

On 6/22/2016 7:54 PM, Brett Frankenberger wrote:
>
>> We are certainly open to other language if you would like to suggest
>> something, to clarify our intent.
>  8.5.4. Initial block
>  
>  Organizations without direct assignments or allocations from ARIN
>  qualify for transfer of an initial block of ARIN's minimum transfer size.
>
> That language suggests that if I am an organization with no direct
> assignment or allocation, I qualify for a transfer of a /24.  What you
> appear to be saying is that the actual policy (due to the contribution
> of 8.5.2) is that I qualify for a /24 if I am an organization with no
> direct assignmetns or allocations, *and* I intend to use them on an
> operational network.
>
> If the latter is the intended policy, I would write it that way:
>
>8.5.4:  Organizations without direct assignments or allocations from
>ARIN qualify for a transfer of an initial block of ARIN's
>minimum transfer size, provided the organization intends to
>use the transferred block on an operational network.
>
> 8.5.2 could then be removed (or, if it was left, it would at least not
> appear inconsistent with 8.5.4.)
>
> (By way of analogy, if our intent is that 8.5.2 would effectively
> impose an additional constraint on an 8.5.4 transfer, then we have an
> NRPM that is conceptually like:
>SECTION A:  All children are entitled to a lollipop.
>SECTION B:  Actually, only children that plan to consume the lollipop
>are entitled to a lollopop.
> That strikes me as poorly drafted.)
Brett,

Thanks for the suggested rewrite for additional clarity.  I'll take that
into account as we consider updates to this policy draft in the future.

Andrew
___
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-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

[Andrew Dul]

Hi Brett,

On 6/22/2016 11:26 AM, Brett Frankenberger wrote:
> On Wed, Jun 22, 2016 at 11:15:58AM -0500, Scott Leibrand wrote:
>> On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns  wrote:
>>
>>> Hi Andrew,
>>>
>>> I have a couple of questions about the policy proposal.
>>>
>>>  On Section 8.5.2 Operational Use.
>>>
>>> First, why is this section even in there, does it serve some particular
>>> purpose?
>>>
>> It prevents financial speculators, who have no operational use for the
>> addresses, from acquiring them for speculative purposes.
> If that's the intent, I think it would better to make "operational
> network" part of the actual requirements, rather than have a general
> "ARIN transfers for the purposes of use on an operational network"
> platitude, and then interpret that as a condition of transfer rather
> than a general statement of a goal we consider worthy.
>
> For example, for an entity wanting to get a /24 under 8.5.4, ARIN would
> first validate that the organization had no existing direct assignments
> or allocations, but then what?  How would they implement 8.5.2?  Ask
> "do you plan to use this on an operational network"?  Request officer
> attestation as to plans to use the /24 on an operational network?  Do
> nothing and approve the transfer on the theory that the requester is on
> his honor to abide by 8.5.2 even without being asked about it?  Approve
> the transfer unless ARIN had some specific reason to believe that the
> proposed transfer was for the purposes of financial speculation? 
> Something else?

The point of 8.5.2 is to clarify that the community believes that IPv4
addresses are to be used on operational networks, not as resources to be
held for some other purpose (e.g. financial speculation).  We ask that
an officer of the organization to attest to ensure that the organization
understands the nature of the transaction and doesn't commit its $ in
support of other goals.  I believe having it in section 8 helps
organizations clearly understand the requirements for transfer.  (e.g.
They don't have to hunt around in other sections for other
requirements.) I, personally, believe that the base requirement for any
transfer is that the organization intend to use it on an operational
network. 


>
> As for 8.5.5, would 8.5.2 be of any effect given that documentation is
> already required. 

8.8.5 is used when 8.5.4 is not used.  So if you are a new org w/o any
address space from ARIN, you have to meet requirements 8.5.1-4.  8.5.5 &
8.5.6 are used for organizations which do not have address space from
ARIN or who want more than the minimum.

>  (Is 8.5.2 the thing that would allow ARIN to reject
> documention along the lines of "we will, within 24 months, make use of
> the transferred space for the purposes of financial speculation"?  That
> seems like overkill; before run-out, ARIN didn't need something like
> 8.5.2 to reject requests for free-pool assignments that came in with a
> justification of "financial speculation" -- I don't know that they
> ever received such, but I'm sure they would have rejected it had they
> received such.)

ARIN would have rejected a free-pool request prior to run-out for a
financial speculator because they didn't show evidence (via needs-test)
how they would be using the addresses on a network.  If we don't have
any requirement that IP number resources are to be used on an
operational network, then an organization can come to ARIN and have
resources transferred into their organization.  ARIN follows the
policies we set, so if our policies are silent about the types of
organizations who are eligible for resources, then ARIN must assume that
all organizations are eligible to receive transferred resources.

We are certainly open to other language if you would like to suggest
something, to clarify our intent.

Andrew


> If we want ARIN to impose an operational network requirement, we should
> be clear what that means. 
>
> All that said, I support the goals of this proposal.  I agree that
> 8.5.2 is non- or poorly- operative (but keeping it would not cause me
> to drop my support for the proposal), and have no opinion on Owen's
> proposal to do it in section 4 rather than 8, but I support the
> elimination of justification for the first /24, and the proposed 8.5.5
> requirements for subsequent or larger tansfers.  I note that it's
> possible that there will be small free-pool assignments made going
> forward, so doing this in section 4, as opposed to section 8, is not a
> purely editorial change.
>
> (Proposed sections referenced above are quoted below for reference.)
>
> 8.5.2. Operational Use
>
> ARIN allocates or assigns blocks of IP addresses to organizations via
> transfer solely for the purpose of use on an operational network.
>   
> 8.5.4. Initial block
> 
> Organizations without direct assignments or allocations from ARIN
> qualify for transfer of an initial block of ARIN's minimum transfer size.

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

[Andrew Dul]

As the primary author of this draft policy, I respectfully disagree with
my AC colleague. 

Now that the free pool has been depleted, it is time to look toward what
future IPv4 (primarily transfer) policy should do.  While this policy
looks complicated, its intention is to create a very simple transfer
policy which allows businesses to predictably and efficiently transfer
IPv4 resources to meet their requirements.

I share with you here a redline which shows the changes that would be
made to section 8.

Andrew

On 6/21/2016 9:16 AM, Owen DeLong wrote:
> I am opposed to this policy proposal.
>
> Given that we are now in a world where the only way to obtain IPv4 space is 
> through transfers, I think it makes much more sense to put policy changes for 
> IPv4 transfers into section 4 and retain the simplified text that exists 
> today in section 8 rather than copying most of section 4 into section 8 with 
> revisions in the process.
>
> The likely outcome of such an exercise is to create a number of changes which 
> may or may not be fully understood by the community. The interaction of this 
> rewrite with other types of transferable resources (AS numbers at the moment) 
> must also be carefully considered.
>
> If we want to change IPv4 policy, then let’s change IPv4 policy in section 4.
>
> If we want to change transfer policy for all resources, we can do that 
> cleanly in section 8.
>
> While the NRPM may not be a perfect model of a structured document, this 
> proposal would make it significantly worse.
>
> Owen
>
>> On Jun 21, 2016, at 09:01 , ARIN  wrote:
>>
>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following 
>> Proposal to Draft Policy status:
>>
>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> This Draft Policy has been numbered and titled:
>>
>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> Draft Policy ARIN-2016-5 is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_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,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>> ##
>>
>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> Date: 21 June 2016
>>
>> Problem Statement
>>
>> Section 4 of the Number Policy Resource Manual was developed over the past 
>> 15+ years primarily to conservatively manage the IPv4 number free pool. 
>> Since the IPv4 free pool was depleted in 2015, the policies which developed 
>> since ARIN's inception may now not be as relevant now that the primary 
>> function of the registry, with regard to IPv4 numbers, is to record 
>> transfers.
>>
>> Since section 4 of the NRPM now contains many use cases that are not as 
>> relevant, it makes sense to streamline the transfer process and to 
>> specifically outline the criteria that should be used to process transfers.
>>
>> Therefore, we propose the following rewrite of the transfer policy, section 
>> 8 of the NRPM.
>>
>> The goals of this rewrite are as follows:
>>
>>> Separate the criteria that is found in section 4 of the NRPM from the 
>>> transfer process.
>>> Provide a clear set of criteria that should be applied across all IPv4 
>>> transfers.
>>> Lower the thresholds on utilization and future allocation size to negate 
>>> the necessity of the corner cases which are currently enumerated in section 
>>> 4 of the NRPM.
>>> Reduce the complexity that is currently required for transfers, by applying 
>>> simpler utilization criteria for current usage, and future allocation 
>>> sizing.
>> Policy statement:
>>
>> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>>
>> ##
>>
>> 8.2. Mergers, Acquisitions, and Reorganizations
>>
>> ARIN will consider requests for the transfer of number resources in the case 
>> of mergers, acquisitions, and reorganizations under the following conditions:
>>
>>> The current registrant must not be involved in any dispute as to the status 
>>> of the resources to be transferred.
>>> The new entity must sign an RSA covering all resources to be transferred.
>>> The resources to be transferred will be subject to ARIN policies.
>>> The minimum transfer size is the smaller of the original allocation size or 
>>> the applicable minimum allocation size in current policy.
>>> For mergers 

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

[Andrew Dul]

Owen, I don't know what data you are using to base your opinion on, but 
by my count of PPML & the PPM.  We have the following number of 
statements regarding the adding of transfer ability (when it is 
restricted to same use).


Support 5

Don't Support 3

Undecided 2

I don't know if 10 individual comments accurately represents the entire 
community regardless of the subject, but that is the public data as I 
counted it.  Additionally, a number of those who were "don't support" 
also noted that they would be "OK" with the transfer addition of the 
text, which as a policy shepherd would generally make the case toward 
support of the changes.


Andrew


On 5/16/2016 11:07 AM, Owen DeLong wrote:
Overall, I do not think that the proposed changes have the support of 
the community and I would advocate leaving the policy as written.


Owen

On May 16, 2016, at 09:39 , Andrew Dul <andrew@quark.net 
<mailto:andrew@quark.net>> wrote:


The shepherds have requested feedback on a proposed update to the 
draft. The draft has not yet been formally updated.


Andrew

On 5/16/2016 8:27 AM, Jason Schiller wrote:

Andrew,

Can you clarify where this policy stands?

I can't tell from your email if you are asking for feed back
on a possible change to the policy. Or if you have actually
rewritten the policy and the AC is requesting comments on
the newly re-written policy.

If the latter, can Sean please update the text at:
https://www.arin.net/policy/proposals/2016_1.html

to show it has been re-written, post the new text there
and a pointer to the now archived older revision?

(e.g. https://www.arin.net/policy/proposals/2015_9.html)

Thanks,

__Jason



On Thu, May 5, 2016 at 10:59 AM, Andrew Dul <andrew@quark.net 
<mailto:andrew@quark.net>> wrote:


Hello,

As part of the discussions at ARIN 37 the community considered
updates to the proposed draft policy that would allow
organizations to transfer, within ARIN, reserved pool resources
provided that they met the criteria to obtain a block from a
reserved pool.

Based upon this feedback we are proposing to update the draft
policy text as follows.  The AC welcomes your feedback on this
proposed text and any other feedback on this draft policy.

Thanks,

Andrew


*Original**Policy statement:*

Add to Section 8.3 and Section 8.4 under the "Conditions on
source of the transfer:"

Address resources from a reserved pool (including those
designated in Section 4.4 and 4.10) are not eligible for transfer.

**Updated ***Policy statement:*

Add to Section 8.3 under the "Conditions on recipient of the
transfer:"

Address resources from a reserved pool (including those
designated in Section 4.4 and 4.10) shall only be transferred to
organizations which meet the current criteria of the reserved
pool from which the resource was obtained.

Add to Section 8.4 under the "Conditions on source of the
transfer:"

Address resources from a reserved pool (including those
designated in Section 4.4 and 4.10) are not eligible for transfer.


___
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 <mailto:i...@arin.net> if you
experience any issues.




--
___
Jason Schiller|NetOps|jschil...@google.com 
<mailto:jschil...@google.com>|571-266-0006




___
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:
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-1: Reserved Pool Transfer Policy

[Andrew Dul]

The shepherds have requested feedback on a proposed update to the
draft.  The draft has not yet been formally updated.

Andrew

On 5/16/2016 8:27 AM, Jason Schiller wrote:
> Andrew, 
>
> Can you clarify where this policy stands?
>
> I can't tell from your email if you are asking for feed back 
> on a possible change to the policy.  Or if you have actually
> rewritten the policy and the AC is requesting comments on 
> the newly re-written policy.
>
> If the latter, can Sean please update the text at:
> https://www.arin.net/policy/proposals/2016_1.html
>
> to show it has been re-written, post the new text there
> and a pointer to the now archived older revision?
>
> (e.g. https://www.arin.net/policy/proposals/2015_9.html)
>
> Thanks,
>
> __Jason
>
>
>
> On Thu, May 5, 2016 at 10:59 AM, Andrew Dul <andrew@quark.net
> <mailto:andrew@quark.net>> wrote:
>
> Hello,
>
> As part of the discussions at ARIN 37 the community considered
> updates to the proposed draft policy that would allow
> organizations to transfer, within ARIN, reserved pool resources
> provided that they met the criteria to obtain a block from a
> reserved pool.
>
> Based upon this feedback we are proposing to update the draft
> policy text as follows.  The AC welcomes your feedback on this
> proposed text and any other feedback on this draft policy.
>
> Thanks,
>
> Andrew
>
>
> *Original**Policy statement:*
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source
> of the transfer:"
>
> Address resources from a reserved pool (including those designated
> in Section 4.4 and 4.10) are not eligible for transfer.
>
> **Updated ***Policy statement:*
>
> Add to Section 8.3 under the "Conditions on recipient of the
> transfer:"
>
> Address resources from a reserved pool (including those designated
> in Section 4.4 and 4.10) shall only be transferred to
> organizations which meet the current criteria of the reserved pool
> from which the resource was obtained.
>
> Add to Section 8.4 under the "Conditions on source of the transfer:"
>
> Address resources from a reserved pool (including those designated
> in Section 4.4 and 4.10) are not eligible for transfer.
>
>
> ___
> 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:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net <mailto:i...@arin.net> if you
> experience any issues.
>
>
>
>
> -- 
> ___
> Jason Schiller|NetOps|jschil...@google.com
> <mailto:jschil...@google.com>|571-266-0006
>

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

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

[Andrew Dul]

Hello,

As part of the discussions at ARIN 37 the community considered updates
to the proposed draft policy that would allow organizations to transfer,
within ARIN, reserved pool resources provided that they met the criteria
to obtain a block from a reserved pool.

Based upon this feedback we are proposing to update the draft policy
text as follows.  The AC welcomes your feedback on this proposed text
and any other feedback on this draft policy.

Thanks,

Andrew


*Original**Policy statement:*

Add to Section 8.3 and Section 8.4 under the "Conditions on source of
the transfer:"

Address resources from a reserved pool (including those designated in
Section 4.4 and 4.10) are not eligible for transfer.

**Updated ***Policy statement:*

Add to Section 8.3 under the "Conditions on recipient of the transfer:"

Address resources from a reserved pool (including those designated in
Section 4.4 and 4.10) shall only be transferred to organizations which
meet the current criteria of the reserved pool from which the resource
was obtained.

Add to Section 8.4 under the "Conditions on source of the transfer:"

Address resources from a reserved pool (including those designated in
Section 4.4 and 4.10) are not eligible for transfer.

___
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-1: Reserved Pool Transfer Policy

[Andrew Dul]

Hello,

The AC would appreciate your feedback on this new draft policy. 

This draft grew out of a conversation at the San Diego NANOG meeting
where it was noted that current policy allows the transfer of IPv4
addresses which are issued to critical infrastructure or as IPv6
transition space.  It was suggested by the authors that this was not
intended and that there are negative consequences of allowing these
transfers to occur. 

Do you support this draft policy?  If not, are there changes that could
be made that would allow you to support it.

Thanks,
Andrew

On 3/22/2016 9:55 AM, ARIN wrote:
>
>
> ## * ##
>
>
> Draft Policy ARIN-2016-1
> Reserved Pool Transfer Policy
>
> Date: 22 March 2016
>
> Problem Statement:
>
> Section 8 of the current NRPM does not distinguish between the
> transfer of blocks from addresses that have been reserved for specific
> uses and other addresses that can be transferred. In sections 4.4 and
> 4.10 there are specific address blocks set aside, based on the need
> for critical infrastructure and IPv6 transitions. Two issues arise if
> transfers of reserved address space occur under the current language
> of section 8. First, if transfers of 4.4 or 4.10 space occur under the
> current policy requirements set forth in sections 8.3 and 8.4, the
> recipients will be able to acquire space that was originally reserved
> for a specific purpose without ever providing evidence that they will
> be using the space for either critical infrastructure or IPv6
> transition. Second, if we allow an allocation or assignment from the
> block reserved in section 4.10 to be transferred out of the region, it
> would complicate the single aggregate from which providers are being
> asked to allow in block sizes smaller than a /24. This policy would
> limit the transfer of addresses from reserved pools.
>
> Policy statement:
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of
> the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> 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.

[arin-ppml] 2-byte ASN policy

[Andrew Dul]

Hello,

I am starting a new thread in PPML, as a follow up to the ARIN 
suggestion and consultation which recently started regarding creating a 
2-byte ASN waiting list.


The original suggestion is here:

https://www.arin.net/participate/acsp/suggestions/2016-04.html

ARIN opened a consultation on this suggestion on the arin-consult 
mailing-list.  This thread starts here for those who are not subscribed 
to arin-consult.


http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html

http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html

As the thread evolved it has been suggested that this issue should be 
resolved via the policy development process rather than through a 
suggestion.


There are a number of questions that have been raised by this thread.  I 
am copying them here to continue the discussion on PPML.


===

Working problem statement: ARIN will receive 2-byte ASNs as  returns 
over time, and these ASNs have perceived or additional value to
organizations compared to 4-byte ASNs.  How should ARIN allocate these 
2-byte ASNs?


===

Should they be given to the next requester, regardless of technical need 
for a 2-byte ASN? (What are the technical qualifications we should use 
if there is a specific technical need?  e.g. provides transit to more 
than 1 ASN?)


If there is really a technical need for 2-byte ASNs, shouldn't we 
attempt to build an inventory of 2-byte ASNs?


Should returns be held in reserve?

Should ARIN hold them for some period of time  before reallocating them?

Should they be put up for auction to  qualified organizations?

Should they be given to the 1st organization  on a wait-list for 2-byte 
ASNs?


Would an organization looking for a 2-byte ASN have the option to 
receive a 4-byte ASN in the interim?  If they did would they have to 
return it?


Should the waiting list be closed to organizations that already have a 
2-byte ASNs?


I and the AC would appreciate your comments on these questions so that 
we can start to build a draft policy that best matches with what the 
community would like to see implemented by ARIN.


Thanks,
Andrew



___
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] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy

[Andrew Dul]

I would think that ARIN staff would already apply a "show me tangible 
evidence requirement" to a 50% within a year requirement.


My understanding is that that is current ARIN staff practice for new 
organizations requires them to show evidence they will actually use the 
IPv4 addresses on an operational network.  I don't think removing the 
immediate/30-day requirement would cause a shift in ARIN operational 
policy to remove the practice of showing documentation to substantiate 
the use of the addresses.


Perhaps ARIN staff could comment on the current operational practices 
for demonstrating usage for new end-users, if that includes a "tangible 
evidence requirement"?


And if the removal of the "immediate" usage of 25% would cause ARIN 
staff in their implementation to not conduct such a requirement on the 
50% within one year test.


Andrew

On 1/29/2016 8:00 AM, Jason Schiller wrote:

McTim,

WRT some other tangible and verifiable claim to show there was a real 
commitment to use half the address space within one year...


I think there are 3 choices:

1. Very vague

Something like "there must be some  tangible and verifiable claim to 
show there was a real commitment to use half the address space within 
one year and not just a future projection or business case"



2. Open ended with some guidance for ARIN staff:

Something like "there must be some  tangible and verifiable claim to 
show there was a real commitment to use half the address space within 
one year and not just a future projection or business case.  Some 
examples include:
- list of equipment in hand to be numbered counting at least 25% of 
requested IP size
- invoices showing equipment purchases demonstrating a commitment to 
buy equipment to be numbered counting at least 25% of requested IP size
- invoices showing equipment purchases demonstrating a commitment to 
buy equipment to be numbered counting at least 50% of requested IP 
size within one year
- lease agreements for real estate supporting equipment that is 
appropratly sized to support equipment to be numbered counting at 
least 50% of requested IP size


3. specific criterion



I don't know what it the right answer here, and suspect it has more to 
do with what the community is comfortable with.


On one end of the spectrum is choice 1.  This allows ARIN to do the 
right thing.  But this also is not clear about what the community 
expects, and  ARIN may act in a way that is counter to what is 
anticipated, and may seem like ARIN is being arbitrary or has too much 
leeway to screw with requestors.


The opposite end of the spectrum is choice 3.  This sets a very clear 
list of what qualifies.  Hammering out that list may be very 
difficult, and it is unlikely to be complete. This will leave little 
or no room for ARIN to do the right thing and approve a request that 
is justified, but not one of the criterion listed.


Choice 2 is the middle ground.  Where we have a not necessarily 
complete list of criterion (so somewhat less difficulty in drawing up 
the list) that creates a very clear expectation of what ARIN should 
accept (and reduces the possibility that ARIN may act in a way that is 
counter to what is anticipated, and may seem like ARIN is being 
arbitrary or has too much leeway to screw with requestors) with 
respect to criterion clearly defined, while also allowing ARIN to do 
the right thing with similar types of proof that are not explicitly 
listed as criterion (this has somewhat higher risk that ARIN may act 
in a way that is counter to what is anticipated, and may seem like 
ARIN is being arbitrary or has too much leeway to screw with 
requestors, but less risk than option 1 as the criterion should serve 
as good guidance)



So two open questions to the community?

1. Is the community most comfortable with:
A. totally vague and open-ended such as "there must be some 
 tangible and verifiable claim to show there was a real commitment to 
use half the address space within one year and not just a future 
projection or business case"


   B. A vague statement with some guidance as to some acceptable forms 
of tangible verifiable proof of a real commitment to use half the IP 
address within one year.


  C. A very clear list of what proof is considered acceptable


2. If the community prefers B. guidance or C. a very clear list then 
what sort of things would the community like to see on that list?



On Fri, Jan 29, 2016 at 8:27 AM, McTim > wrote:




On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller
> wrote:

I support the removal of the 30 day utilization as it is
unreasonable for any larger end-site, who may have a real need
for say a /16, with 65,000 desktops arriving on a loading doc
next week, but an inability to unbox, configure and deploy
16,384 to the various office locations in 30 days.

Re: [arin-ppml] Transition /10

[Andrew Dul]

The ARIN community previously considered these ideas under 2014-16, but 
changing the /10 to something other than transition never had sufficient 
support for the AC to move it forward.

https://www.arin.net/policy/proposals/2014_16.html

.Andrew

> On Oct 20, 2015, at 5:35 PM, Morizot Timothy S  
> wrote:
> 
> Thanks for the clarifications. In that context, assuming a new entrant is 
> deploying IPv6, wouldn't the current policy allow them to request allocations 
> to support that deployment. It specifically mentions needs like dual-stacked 
> nameservers and various IPv4 life extension solutions. If a new entrant 
> *isn't* deploying IPv6 from the start, do we really want to support them with 
> a free pool allocation? For any needs beyond those described in the policy, 
> there's the transfer market. I don't know that I have particularly strong 
> feelings either way, but if we're going to reserve any general use pool at 
> all rather than simply handing it all out to meet current need, I think it's 
> better to tie it to demonstrated IPv6 deployment.
> 
> Scott
> 
> -Original Message-
> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On 
> Behalf Of Spears, Christopher M.
> Sent: Tuesday, October 20, 2015 10:21 AM
> To: Hadenfeldt, Andrew C
> Cc: arin-ppml@arin.net
> Subject: Re: [arin-ppml] Transition /10
> 
> NRPM 4.10 [1] dedicated /10 for IPv6 "transition"..
> 
> I tossed a similar idea around with some folks at ARIN36.   Use this /10 to 
> allocate a /24 per **new** Org, and steer subsequent transactions to 
> transfers.   That would ensure IPv4 for ~16K **new** entrants in the coming 
> years..   
> 
> [1] https://www.arin.net/policy/nrpm.html#four10
> 
> ___
> 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-2015-8: Reassignment records for IPv4 End-Users

[Andrew Dul]

There are a number of community members that posit that if reassignment records 
are allowed for end-users "bad" things might happen and thus seek to limit the 
number or scope of the records that could be added.  

To me the issue of ISP vs end-user and the downstream effect on ARIN's revenue 
is some what a side issue.  I believe the ARIN board will adjust appropriately 
should the lines between ISP and end-user blur enough to warrant a fee schedule 
change.  

We can improve the quality of data about IP address records by allowing users 
to add additional information.  One might argue that this additional 
information is not always accurate, but personally I'd rather have additional 
information (which may not be helpful) rather than no information.

Andrew

> On Oct 6, 2015, at 3:14 PM, Spears, Christopher M.  wrote:
> 
> What about setting a limit on the amount of space that can be re-assigned, or 
> the number of re-assignments?  Say 25% of the maximum possible reassignments 
> using the current minimum reassignment size (/29), based on the upper bound 
> of the fee category they're in (e.g., xx-small = /22 = 1024*.25/8 = 32 
> re-assignmentsl). Or up 50% of the assigned space?
> 
> It’s also worth noting that this only addresses IPv4 re-assignments under 
> Section 4.  There should be parity for IPv6 (which I understand is currently 
> a draft).   Doing them in tandem would give this more weight, IMHO.
> 
> End-users make up over 40% of the Orgs in the ARIN region. If a “single” 
> policy is a desired outcome, then we should either make accommodations for 
> End Users that starts to level the field, or create a middle-ground that’s 
> acceptable should things stall.  Half-measure are often rebuked because they 
> potentially leave you in an unenviable (or untenable) state.
> 
> -Chris
> 
> 
> 
>> On Oct 5, 2015, at 3:39 PM, David Farmer  wrote:
>> 
>> Marla,
>> 
>> From a strategic point of view I agree that we should move to a one policy 
>> for everyone model.
>> 
>> However, every time we try all-encompassing strategic changes, people say 
>> they are too big of a change all at once, and tell us to break them up.  
>> When we brake them up into manageable size chunks, the individual changes 
>> don't get support because people don't want to see half-measures they want 
>> strategic level changes.
>> 
>> This is a catch 22. We need to find a way to move forward. How would you 
>> suggest we do that?
>> 
>> Thanks.
>> 
>>> On 10/5/15 13:55 , Azinger, Marla wrote:
>>> I don't support this based on what I see as a missed opportunity.  This 
>>> policy calls attention to the fact that ARIN should consider removing any 
>>> difference in policy between End Users and ISPs.  I agree this proposal has 
>>> valid case use scenarios, however it just leaves me thinking only one 
>>> "class" is needed and not two.  One policy for all.
>>> 
>>> Regards
>>> Marla Azinger
>>> 
>>> -Original Message-
>>> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On 
>>> Behalf Of ARIN
>>> Sent: Tuesday, August 25, 2015 12:12 PM
>>> To: arin-ppml@arin.net
>>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for 
>>> IPv4 End-Users
>>> 
>>> Draft Policy ARIN-2015-8
>>> Reassignment records for IPv4 End-Users
>>> 
>>> On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222 
>>> Reassignment records for IPv4 End-Users" as a Draft Policy.
>>> 
>>> Draft Policy ARIN-2015-8 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2015_8.html
>>> 
>>> You are encouraged to discuss the merits and your concerns of Draft Policy 
>>> 2015-8 on the Public Policy Mailing List.
>>> 
>>> 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 PDP. Specifically, these principles are:
>>> 
>>>* Enabling Fair and Impartial Number Resource Administration
>>>* Technically Sound
>>>* Supported by the Community
>>> 
>>> The ARIN Policy Development Process (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,
>>> 
>>> Communications and Member Services
>>> American Registry for Internet Numbers (ARIN)
>>> 
>>> 
>>> ## * ##
>>> 
>>> 
>>> Draft Policy ARIN-2015-8
>>> Reassignment records for IPv4 End-Users
>>> 
>>> Date: 25 August 2015
>>> 
>>> Problem statement:
>>> 
>>> End-User Organizations do not have the ability to create reassignment 
>>> records in the number resource database.
>>> 
>>> Reassignment records can be used for a number of different functions which 
>>> could benefit the overall desire to increase database accuracy by allowing 
>>> organizations to add additional details in the database.
>>> 
>>> The following reasons have been noted as 

Re: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations

[Andrew Dul]

The intent here is to clarify that a reorganization is not required to go 
through the larger process of showing that assets were acquired and the other 
needs testing that is currently done on mergers & acquisitions.   

Andrew

> On Oct 5, 2015, at 3:26 PM, Azinger, Marla  wrote:
> 
> It looks like all that was changed was they added the word “re-organization”. 
>  Am I missing some other text change?
> 
> Regards
> Marla Azinger
> 
> -Original Message-
> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On 
> Behalf Of ARIN
> Sent: Tuesday, July 21, 2015 10:33 AM
> To: arin-ppml@arin.net
> Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-4: Modify 8.2 section 
> to better reflect how ARIN handles reorganizations
> 
> Recommended Draft Policy ARIN-2015-4
> Modify 8.2 section to better reflect how ARIN handles reorganizations
> 
> On 16 July 2015 the ARIN Advisory Council (AC) recommended
> ARIN-2015-4 for adoption, making it a Recommended Draft Policy.
> 
> ARIN-2015-4 is below and can be found at:
> https://www.arin.net/policy/proposals/2015_4.html
> 
> You are encouraged to discuss Draft Policy 2015-4 on the PPML prior to the 
> ARIN Public Policy Consultation at ARIN 36 in Montreal in October 2015. Both 
> the discussion on the list and at the meeting will be used by the ARIN 
> Advisory Council to determine the community consensus for adopting this as 
> policy.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Recommended Draft Policy ARIN-2015-4
> Modify 8.2 section to better reflect how ARIN handles reorganizations
> 
> Date: 21 July 2015
> 
> AC's assessment of conformance with the Principles of Internet Number 
> Resource Policy:
> 
> 2015-4 is largely editorial in nature and does not change policy 
> implementation, but clarifies existing use of policy. The proposal is fair in 
> that it provides a consistent interface for transfers and clarifies the 
> transfer policy. It is technically sound in that it is already effectively 
> implemented. The proposal has received support on the mailing list and we 
> expect it to be generally supported by the community as it is the direct 
> result of community feed back on the existing policy.
> 
> Problem Statement:
> 
> ARIN staff indicated that NRPM 8.2 does not clearly indicate how ARIN 
> procedures handle reorganizations. ARIN staff indicated that the first policy 
> bullet point does not apply to reorganizations.
> 
> Policy statement:
> 
> Replacement text for entire 8.2 section:
> 
> 8.2. Mergers, Acquisitions, and Reorganizations
> 
> ARIN will consider requests for the transfer of number resources in the case 
> of mergers, acquisitions, and reorganizations under the following
> conditions:
> 
> -The current registrant must not be involved in any dispute as to the status 
> of the resources to be transferred.
> 
> -The new entity must sign an RSA covering all resources to be transferred.
> 
> -The resources to be transferred will be subject to ARIN policies.
> 
> -The minimum transfer size is the smaller of the original allocation size or 
> the applicable minimum allocation size in current policy.
> 
> -For mergers and acquisition transfers, the recipient entity must provide 
> evidence that they have acquired assets that use the resources to be 
> transferred from the current registrant. ARIN will maintain an up-to-date 
> list of acceptable types of documentation.
> 
> In the event that number resources of the combined organizations are no 
> longer justified under ARIN policy at the time ARIN becomes aware of the 
> transaction, through a transfer request or otherwise, ARIN will work with the 
> resource holder(s) to return or transfer resources as needed to restore 
> compliance via the processes outlined in current ARIN policy.
> 
> Comments:
> 
> The problem statement is addressed by:
> 
> -re-title 8.2
> 
> -clarify the documentation bullet point
> 
> -rearrange the documentation bullet to the end of the list since it only 
> applies to some requestors, while the other bullet points apply to all 
> requestors.
> 
> a.Timetable for implementation: Immediate
> 
> b.Anything else
> 
> #
> 
> ARIN STAFF & LEGAL ASSESSMENT
> Draft Policy ARIN-2015-4
> Modify 8.2 section to better reflect how ARIN handles reorganizations 
> https://www.arin.net/policy/proposals/2015_4.html
> 
> Date of Assessment: July 14, 2015
> 
> ___
> 1. Summary (Staff Understanding)
> This proposal would provide clarification to the 8.2 transfer policy for 
> reorganizations. It does this by adding "reorganizations" to the title, and 
> clarifies that evidence of acquired assets is only required for merger and 
> 

Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks

[Andrew Dul]

On 9/26/2015 12:11 PM, Elvis Daniel Velea wrote:
> Owen,
>
> On 25/09/15 20:24, Owen DeLong wrote:
>> Please provide the metrics on which you base this assertion. How was
>> RIPE-NCC accuracy measured prior to the policy change and to what
>> extent was it improved as a result of this policy change. What
>> mechanism was used to determine that the measured increase in
>> accuracy was the result of the particular policy abandoning
>> needs-based evaluation?
>>
> just have a look at the number of transfers pre-2013-03 and the number
> of transfers after the policy proposal was implemented.
>
> Basically, transfers via the RIPE NCC (recorded in the registry) have
> become the standard for everyone in the RIPE region, financial
> artifices have not been used anymore (as far as I know) once the
> need-based barrier has been removed.
>

Just because there are more transfers, one cannot know for sure that the
data is more accurate.  The number of transfers may be increasing for
other reasons.  It is possible that the data is more accurate, but just
saying "see there are more transfers" does not mean the database is more
accurate.

Andrew


___
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-2015-8: Reassignment records for IPv4 End-Users

[Andrew Dul]

On 8/26/2015 12:08 PM, Gary T. Giesen wrote:

Andrew,

If that's your approach, why not create policy to create one class of user,
and remove the distinction altogether?
I have contemplated such an approach and even drafted, about 2 years 
ago, a post-IPV4-exhaustion policy rewrite, which collapsed the 
distinction between ISPs and end-users.  In discussing this idea within 
the AC and other community members, they believed at that time that was 
too much for the community to handle.  The community in the past has 
noted that omnibus style policy rewrites are generally not accepted by 
the larger community.


This policy proposal is a way to start the discussion between the ISP / 
end-user differences.  If the wider community support the idea of fully 
collapsing the two categories, we can continue that direction.  If not, 
that is OK, too.




ISPs pay more because they receive
more in services, and because they make money leasing IPs. If you make it
so that ISPs can get the same set of services as end users (and start
applying as end-users), then end-user fees will have to increase
appropriately, in order to avoid decreasing ARIN's overall revenues. A lot
of end-users will not want that, to satisfy the wants of a few very large
orgs, for a service which they may even not know exists (and have no desire
to use it)

All I'm talking about is putting in some language to guard against obvious
fraud, and keep costs down for end-users (since they presumably won't have
anywhere near the ratio of SWIPs/block). It's not going to stop an ISP
determined to go the end-user route, but will hopefully steer the
well-meaning ISPs down the correct path and could make it easier to revoke
blocks for blatent fraud.


Do you have any language that you'd like to see added to the draft such 
that you could support it?



A lot of what's in the NRPM already is hard to enforce, but that doesn't
stop us from trying to create policies for fair allocations/assignments,
with reasonable controls. I think some plain language about what is and is
not an acceptable SWIP for an end-user is appropriate. What I don't want to
see if the ISP/end-user classes merging by being back-doored through a
policy with no limits.


Some of the examples of what I thought were acceptable reassignments I 
put in the problem statement.  Would you support those types of 
reassignment records being allowed for end-users?


Andrew


-Original Message-
From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
Behalf Of Andrew Dul
Sent: August 26, 2015 2:34 PM
To: arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records

for

IPv4 End-Users

Shouldn't operators get to decide and be responsible for what records they
put in the database?  I understand that the potential for mis-use of

additional

reassignments, but there is already that potential for ISPs.  Do you feel

that

we need to address mis-use with ISP reassignments too?

One could create all sorts of schemes to limit the ability of ISP users

to

game the system as end users.  Fee per reassignment record, or 10
reassignments per end-user w/ additional records costing more...

Or maybe we just need to think about if the differences between ISPs and
end-users matter as much in a IPv4 depleted world.

While this policy likely has downstream fee implications, it is not

designed to

map to any particular fee structure.  I haven't seen any details on any
proposed fee changes so I could not take that into account when drafting

this

policy.

Andrew

On 8/26/2015 10:18 AM, Gary T. Giesen wrote:

I am opposed to the policy as written.

There are few to no controls on who the end user can SWIP to, which I
think will either result in ISPs applying as end-users to game the
system, raise the cost for end users, or both.

I assume this is trying to align the NRPM to ARIN's new fee structure
which I believe is due in September?

Cheers,

GTG


-Original Message-
From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net]
On Behalf Of ARIN
Sent: August 25, 2015 3:12 PM
To: arin-ppml@arin.net
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
for

IPv4

End-Users

Draft Policy ARIN-2015-8
Reassignment records for IPv4 End-Users

On 20 August 2015 the ARIN Advisory Council (AC) accepted
ARIN-prop-222 Reassignment records for IPv4 End-Users as a Draft

Policy.

Draft Policy ARIN-2015-8 is below and can be found at:
https://www.arin.net/policy/proposals/2015_8.html

You are encouraged to discuss the merits and your concerns of Draft
Policy
2015-8 on the Public Policy Mailing List.

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 PDP. Specifically, these principles are:

 * Enabling Fair and Impartial Number Resource Administration
 * Technically Sound
 * Supported by the Community

The ARIN Policy

Re: [arin-ppml] 2015-8

[Andrew Dul]

On 8/27/2015 4:45 AM, Rudolph Daniel wrote:


This policy proposal stretches across responsibilities areas as it 
impacts

 number policy, ARIN operational practice, and fees.

What would the result of orgs. being allowed to create re assignment 
records, yet failing to do so? Or, what would be their motivation to 
maintain an acceptible level of accuracy?




The way the policy is written so far, additional reassignment records, 
are optional.  If the community wanted to see end-users add reassignment 
records as a requirement, that is a discussion that the community should 
have and draft those expectations into policy.


Andrew
___
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-2015-8: Reassignment records for IPv4 End-Users

[Andrew Dul]

Shouldn't operators get to decide and be responsible for what records
they put in the database?  I understand that the potential for mis-use
of additional reassignments, but there is already that potential for
ISPs.  Do you feel that we need to address mis-use with ISP
reassignments too?

One could create all sorts of schemes to limit the ability of ISP
users to game the system as end users.  Fee per reassignment record,
or 10 reassignments per end-user w/ additional records costing more...

Or maybe we just need to think about if the differences between ISPs and
end-users matter as much in a IPv4 depleted world. 

While this policy likely has downstream fee implications, it is not
designed to map to any particular fee structure.  I haven't seen any
details on any proposed fee changes so I could not take that into
account when drafting this policy.

Andrew

On 8/26/2015 10:18 AM, Gary T. Giesen wrote:
 I am opposed to the policy as written.

 There are few to no controls on who the end user can SWIP to, which I think
 will either result in ISPs applying as end-users to game the system, raise
 the cost for end users, or both. 

 I assume this is trying to align the NRPM to ARIN's new fee structure which
 I believe is due in September?

 Cheers,

 GTG

 -Original Message-
 From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
 Behalf Of ARIN
 Sent: August 25, 2015 3:12 PM
 To: arin-ppml@arin.net
 Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
 IPv4
 End-Users

 Draft Policy ARIN-2015-8
 Reassignment records for IPv4 End-Users

 On 20 August 2015 the ARIN Advisory Council (AC) accepted ARIN-prop-222
 Reassignment records for IPv4 End-Users as a Draft Policy.

 Draft Policy ARIN-2015-8 is below and can be found at:
 https://www.arin.net/policy/proposals/2015_8.html

 You are encouraged to discuss the merits and your concerns of Draft Policy
 2015-8 on the Public Policy Mailing List.

 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 PDP. Specifically, these principles are:

 * Enabling Fair and Impartial Number Resource Administration
 * Technically Sound
 * Supported by the Community

 The ARIN Policy Development Process (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,

 Communications and Member Services
 American Registry for Internet Numbers (ARIN)


 ## * ##


 Draft Policy ARIN-2015-8
 Reassignment records for IPv4 End-Users

 Date: 25 August 2015

 Problem statement:

 End-User Organizations do not have the ability to create reassignment
 records in the number resource database.

 Reassignment records can be used for a number of different functions which
 could benefit the overall desire to increase database accuracy by allowing
 organizations to add additional details in the database.

 The following reasons have been noted as positive reasons to allow the
 creation of additional records.
 - Geolocation (allows an organization to specify a different location
 within the
 database which is used by organizations creating geo-location by IP
 address
 databases)
 - Subsidiary reassignment (allows an organization to note that a portion
 of
 their netblock is in use by a different subsidiary entity)
 - Assignment to contracted parties (some organizations have contracts with
 other organizations which are operating networks under agreements with
 the registrant, this allows the top-level organizations to accurately
 specify the
 organization operating the network in the number resource database)
 - More specific contact information (some organizations operate large
 networks which don't necessarily have the same technical or abuse contact
 information)

 Policy statement:

 Create new section 4.3.x

 End-user organizations which have an active registration services
 agreement
 shall be permitted to create reassignment records in the number resource
 database. Organizations shall use the guidelines outlined in section 4.2.3
 when creating reassignment records.

 Comments:
 a. Timetable for implementation: immediately b. Anything else:

 It is noted by the author of this policy proposal that one of the
 distinctions in
 the service between ISPs and End-Users has been the ability for an
 organization to create reassignment records.

 This policy proposal stretches across responsibilities areas as it impacts
 number policy, ARIN operational practice, and fees.

 Below we have noted the three areas and the different responsibilities:

 A) Providing reassignment support for end-user assignments, for those who
 wish to use it

 This is an ARIN Service issue - could be an suggestion/consultation
 process,
 so long as any implied additional workload/cost can be accommodated in
 budget and the 

Re: [arin-ppml] Policy Proposal Idea: Reassignment records for IPv4 End-Users

[Andrew Dul]

The intention is to allow for end-users to be able to add reassignment
records to the database.  As noted in the policy proposal, this idea has
an impact of the fee categories, because the ability to add reassignment
records traditionally has been one of the differences between ISPs and
end-users.

I think we need to consider if the categories of IPv4 ISP and end-users
have any significance now that the IPv4 free pool has been exhausted. 

I will let ARIN staff comment on the cost/workload aspects of this
change idea. 

The fees themselves are the purview of the board.  Since this policy
changes the service levels that ARIN would provide to end-users one
might expect that the fee levels might change for organizations which
choose to take advantage of the additional functionality.

Andrew

On 7/14/2015 8:08 AM, Gary T. Giesen wrote:
 Andrew,

 Is it your intention to create a single class of users (ie. no more End-User 
 vs ISP), or maintain the distinction? I'd like to see end-users be able to 
 SWIP, but I'd don't want to see their costs increase because of it. Also, 
 ISPs will argue if end-users can SWIP (which is probably the biggest 
 technical distinction between the two right now ) and pay far less, they'll 
 either argue their fees should be lowered, the end users fees should be 
 raised, or try to game the system by applying as end-users.

 Do we have any indication from ARIN staff as to what the implications in 
 terms of cost/workload would be if end-users would be allowed to SWIP? Again, 
 if the impact is minimal (ie no raising of end-user fees) and sufficient 
 language was put around who they could SWIP to (ie only organizations in 
 which the parent owns a controlling share, etc) then I would support this.

 Cheers,

 GTG 

 -Original Message-
 From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
 Behalf Of Andrew Dul
 Sent: July 13, 2015 11:31 AM
 To: arin-ppml@arin.net
 Subject: [arin-ppml] Policy Proposal Idea: Reassignment records for IPv4 End-
 Users

 The AC has been discussing the following ideas on their list and I have 
 drafted
 the following policy proposal as an outcome.  We are posting the ideas and
 proposal here to PPML for community discussion.  This draft has not been
 submitted formally to the PDP process at this point.  I believed having 
 initial
 feedback from the community before submitting would be a valuable
 addition before going into the formal process.

 You comments are welcome.

 Thanks,
 Andrew


 

 Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0

 1.Policy Proposal Name: Reassignment records for IPv4 End-Users

 4.Problem Statement:

 End-User Organizations do not have the ability to create reassignment
 records in the number resource database.

 Reassignment records can be used for a number of different functions which
 could benefit the overall desire to increase database accuracy by allowing
 organizations to add additional details in the database.

 The following reasons have been noted as positive reasons to allow the
 creation of additional records.
 -Geolocation (allows an organization to specify a different location
 within the database which is used by organizations creating geo-location by
 IP address databases)
 -Subsidiary reassignment (allows an organization to note that a
 portion of their netblock is in use by a different subsidiary entity)
 -Assignment to contracted parties (some organizations have contracts
 with other organizations which are operating networks under agreements
 with the registrant, this allows the top-level organizations to accurately
 specify the organization operating the network in the number resource
 database)
 -More specific contact information (some organizations operate large
 networks which don’t necessarily have the same technical or abuse contact
 information)


 5.Policy statement:

 Create new section 4.3.x

 End-user organizations which have an active registration services agreement
 shall be permitted to create reassignment records in the number resource
 database.  Organizations shall use the guidelines outlined in section 4.2.3
 when creating reassignment records.

 6.Comments:
  a.Timetable for implementation: immediately
  b.Anything else:

 It is noted by the author of this policy proposal that one of the 
 distinctions in
 the service between ISPs and End-Users has been the ability for an
 organization to create reassignment records.

 This policy proposal stretches across responsibilities areas as it impacts
 number policy, ARIN operational practice, and fees.

 Below we have noted the three areas and the different responsibilities:


 A)Providing reassignment support for end-user assignments, for those
 who wish to use it

 This is an ARIN Service issue - could be an suggestion/consultation process,
 so long as any implied additional workload/cost can be accommodated in
 budget and the community supports

 B) New

[arin-ppml] Policy Proposal Idea: Reassignment records for IPv4 End-Users

[Andrew Dul]

The AC has been discussing the following ideas on their list and I have 
drafted the following policy proposal as an outcome.  We are posting the 
ideas and proposal here to PPML for community discussion.  This draft 
has not been submitted formally to the PDP process at this point.  I 
believed having initial feedback from the community before submitting 
would be a valuable addition before going into the formal process.


You comments are welcome.

Thanks,
Andrew




Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0

1.Policy Proposal Name: Reassignment records for IPv4 End-Users

4.Problem Statement:

End-User Organizations do not have the ability to create reassignment 
records in the number resource database.


Reassignment records can be used for a number of different functions 
which could benefit the overall desire to increase database accuracy by 
allowing organizations to add additional details in the database.


The following reasons have been noted as positive reasons to allow the 
creation of additional records.
-Geolocation (allows an organization to specify a different location 
within the database which is used by organizations creating geo-location 
by IP address databases)
-Subsidiary reassignment (allows an organization to note that a 
portion of their netblock is in use by a different subsidiary entity)
-Assignment to contracted parties (some organizations have contracts 
with other organizations which are operating networks under agreements 
with the registrant, this allows the top-level organizations to 
accurately specify the organization operating the network in the number 
resource database)
-More specific contact information (some organizations operate large 
networks which don’t necessarily have the same technical or abuse 
contact information)



5.Policy statement:

Create new section 4.3.x

End-user organizations which have an active registration services 
agreement shall be permitted to create reassignment records in the 
number resource database.  Organizations shall use the guidelines 
outlined in section 4.2.3 when creating reassignment records.


6.Comments:
a.Timetable for implementation: immediately
b.Anything else:

It is noted by the author of this policy proposal that one of the 
distinctions in the service between ISPs and End-Users has been the 
ability for an organization to create reassignment records.


This policy proposal stretches across responsibilities areas as it 
impacts number policy, ARIN operational practice, and fees.


Below we have noted the three areas and the different responsibilities:


A)Providing reassignment support for end-user assignments, for those 
who wish to use it


This is an ARIN Service issue - could be an suggestion/consultation 
process, so long as any implied additional workload/cost can be 
accommodated in budget and the community supports


B) New requirement on end-users to provide reassignment information in 
certain circumstances so that ARIN will treat their usage assertion credibly


This is a policy issue.  These requirements should be vetted through the 
policy development process.


C)Fee Implications of ISPs moving to end-user category

This is Board issue, but first requires a community discussion or 
consultation to be held to solicit community input on desired outcome.




___
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-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments

[Andrew Dul]

On 6/25/2015 6:14 AM, William Herrin wrote:
 On Tue, Jun 23, 2015 at 4:07 PM, ARIN i...@arin.net wrote:
 Recommended Draft Policy ARIN-2015-1
 Modification to Criteria for IPv6 Initial End-User Assignments
 On second thought, I withdraw my support and oppose the policy draft
 as written. While I approve of the policy in concept, the draft
 commits two errors which should be rectified before it goes to the
 board:

 First, it replaces large sections of text to which there is no
 obvious modification. This lacks clarity, making it needlessly
 difficult to understand what the draft actually changes. The draft
 should be winnowed to just the text which changes.

 Second, it renumbers existing 6.5.8.1e to 6.5.8.1f and then replaces
 6.5.8.1e with text which is not derivative of the original. This is
 bad practice, as it confuses external references to the NRPM. Indeed,
 ARIN's normal practice has been to retire rather than replace or
 reorder section numbers which no longer serve their original function.

 With those two changes made, I believe I would support the draft.


Just so I understand you are opposed to the 'editorial' way the policy
was written, not the content of the actual changes?

Andrew
___
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] 2014-1 (Out of region use)

[Andrew Dul]

Here is a suggested addition to the draft policy's first paragraph in an 
attempt to alleviate some of the issues raised by the staff  legal 
assessment by increasing the nexus requirement slightly.



Out of region use of IPv4, IPv6, or ASNs are valid justification for 
additional number resources if the applicant is currently using at least 
the equivalent of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN 
service region, respectively.  At least 10% of the additional resource 
request or 20% of all an organization’s resources must be used in the 
ARIN service region.





___
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-2014-14: Needs Attestation for some IPv4 Transfers - Revised

[Andrew Dul]

This policy draft has been significantly revised by the AC, including a
new problem statement and substantially different draft policy
language.  Conversation on PPML so far has been quite limited on this
new draft.  The AC would like to hear from members of the community on
this new language.  Specifically if you could address the following
questions it would be appreciated.

Do you agree with the new problem statement?

Do you support the new policy language?  If not, are there areas of the
text which could be modified so that you could support the draft?

If you don't support this revised language, do you believe the AC should
abandon this draft policy?

Thanks for your feedback,
Andrew

On 2/24/2015 9:17 AM, ARIN wrote:
 ARIN-2014-14 has been revised. This draft policy is open for discussion
 on this mailing list.

 ARIN-2014-14 is below and can be found at:
 https://www.arin.net/policy/proposals/2014_14.html

 Regards,

 Communications and Member Services
 American Registry for Internet Numbers (ARIN)


 ## * ##


 Draft Policy ARIN-2014-14
 Needs Attestation for some IPv4 Transfers

 Date: 24 Feb 2015

 Problem Statement:

 The process of 'needs testing' or 'needs basis' allocation has evolved
 over the history of the Internet registry system. The earliest number
 resource policy required that an operator intend to use the number
 resources on an operational Internet Protocol network before the
 resource would be registered to an organization. Organizations were
 assigned either a Class A, B, or C block roughly depending on the
 organization's size. With the implementation of CIDR, additional 'needs
 testing' was done to right size allocations to fit organizations. These
 testing requirements continued to evolve under various organizations
 prior to the RIRs inception and then later formally under the RIR's
 policy development process.

 In the 2000s, ARIN began a systematic trust but verify process for
 IPv4 requests. This was necessary due to both IPv4 address registration
 hijackings in ARIN Whois and the accelerated amount of systematic fraud
 being perpetrated on ARIN.

 As IPv4 exhaustion occurred, some RIRs have reconsidered the necessity
 of some of the needs testing requirements and implemented policies
 which reduced the requirements on organizations to show need or
 utilization for some transfer transactions with the RIR.

 The cost of performing a needs assessment and auditing of this
 information vs. the public benefit of restricting allocations to
 specifically qualified organizations has been noted by some
 organizations to be out of alignment. The ability to predict future use
 toward a 24-month utilization rate can also be challenging for some
 organizations and relies on projections and estimates rather than
 verifiable facts. Thus, the current needs testing requirements may be
 more than is necessary and desirable for small transfers. This policy
 seeks to reduce the complexity of transfers by removing the utilization
 needs testing requirement and replacing it with a needs attestation by
 a corporate officer.

 Additionally, other requirements are placed around the 'needs
 attestation only' requirement to reduce the Number Resource Community's
 concern that this type of policy could be abused for speculation or
 hording. Furthermore, the policy includes a sunset clause to limit the
 total number of transfers under this policy proposal. This sunset is
 intended to force the community to reexamine the success or failure of
 the practices contained in this policy proposal.

 Policy statement:

 Section 8.3

 Replace the 'Conditions on recipient of the transfer' with
 the following conditions.

 Conditions on recipient of the transfer:

   The organization must sign an RSA.

   The resources transferred will be subject to current ARIN policies.

 In addition, the recipient must meet one of the following requirements
 sets:

 1. The organization must demonstrate the need for up to a 24-month
 supply of IP address resources under current ARIN policies.

 OR

 1.The organization, its parent(s), or subsidiary organizations, must
 not have received IPv4 address resources, via transfer, within the
 past 12 months.

 2.An officer of the organization must attest that the IPv4 address
 block is needed for and will be used on an operational network.

 3.The maximum transfer size is /20.

 4.Fewer than 5,000 needs attestation transfers have occurred.


 Section 8.4

 Replace the 'Conditions on recipient of the transfer' with
 the following conditions.

 Conditions on recipient of the transfer:

   The conditions on a recipient outside of the ARIN region will be
   defined by the policies of the receiving RIR.

   Recipients within the ARIN region will be subject to current ARIN
   policies and sign an RSA for the resources being received.

   The minimum transfer size is a /24.

 In addition, the recipient must meet one of the following requirements
 sets:

 1. The organization must demonstrate 

Re: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers - Revised

[Andrew Dul]

On 2/24/2015 12:55 PM, Gary Buhrmaster wrote:
 On Tue, Feb 24, 2015 at 5:17 PM, ARIN i...@arin.net wrote:
 ARIN-2014-14 has been revised. This draft policy is open for discussion
 on this mailing list.
 
 Draft Policy ARIN-2014-14
 Needs Attestation for some IPv4 Transfers
 Trying to better understand the details.

 2.An officer of the organization must attest that the IPv4 address
 block is needed for and will be used on an operational network.
 So no time frame at all for usage in their organization?
 Any time frame is OK?  Any organization is OK?

I believe based upon the current text, the answers to these 3 questions
is yes.


 
 4.Fewer than 5,000 needs attestation transfers have occurred.
 Where did the 5000 come from?  WAG?  If I calculated
 this correctly, that would mean somewhere between a
 /12 and a /8 could fall under attestation only.

It is basically a WAG.  Originally on the AC list 10,000 was proposed. 
Why 10,000?  On average over the past 5 years, ARIN has made about 2,000
allocations or assignments per year.  Some members of the AC noted a
smaller number was needed, and thus the next draft reduced it to 5,000.

Do you support this number?  If not, is there a number you would be more
comfortable with?

Thanks,
Andrew

___
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-2014-21: Modification to CI Pool Size per Section 4.4

[Andrew Dul]

David,

I'd like to propose the following rewrite of this section as replacement
text for ARIN-2014-21.  I believe this rewrite deals with the clarity
issues that you have noted.  I believe this rewrite does not change
operational practice (other than the /15 replacing the current /16), but
provides some needed clarity in this section from multiple amendments
over the years. 




*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 when operational need can be documented.

ARIN will place an equivalent of a /15 of IPv4 address space in a
permanent reserve for micro-allocations and shall use sparse allocations
practices where applicable.

*4.4.1 Internet Exchange Points*

Exchange point allocations MUST be allocated from specific blocks
reserved only for this purpose. All other micro-allocations WILL be
allocated out of other blocks reserved for micro-allocation purposes.
ARIN will make a list of these blocks publicly available.

Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of
three total), ASN, and contact information. This policy does not
preclude exchange point operators from requesting address space under
other policies.

*4.4.2 gTLD Allocations*

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 blocks reserved in
section 4.4. This limit of a /23 equivalent per gTLD does not apply to
gTLD allocations made under previous policy.

*4.4.3 Other Critical Infrastructure*

Other critical infrastructure, such as ICANN-sanctioned root and ccTLD
operators, as well as the RIRs and IANA, may receive allocations from
ARIN, when operational need can be demonstrated.

 



On 12/22/2014 2:48 PM, David Farmer wrote:
 So far there has been very little discussion on this policy.

 Therefore, as one of the AC shepherds for this policy I would like to
 initiate some discussion of this policy.  Here are a few questions for
 the ARIN community to think about and provide feedback on;

 - The current CI reservation is for all CI not just IXPs, the problem
 statement discusses growth primarily in the IXPs as justification to
 expand the reservation.  Should we split off a separate reservation
 pool for IXPs?  Or, keep the current common CI pool?

 - ARIN-2011-4 the policy that made the original CI reservation had a
 Policy Term of 36 Months following implementation, but this was not in
 the policy text itself and therefore did not get included in the NRPM.

 https://www.arin.net/policy/proposals/2011_4.html

 If applicable, this would have expired July 2014.  So, should there be
 expiration date included in this policy text?  If there should be no
 expiration date, should we explicitly note the removal of any
 expiration date in the discussion of this policy?

 - There was discussion of smaller and larger than /24 IXP allocations,
 like /26 on the smaller side and that some very large IXPs are
 starting to need as large as a /22.  Also discussed was, sparse
 allocation for IXPs to allow expansion without renumbering.  Should
 this policy includes any changes along these lines?  Why or why not?

 - Should we try to get this to the PPC at NANOG 63 in San Antonio as a
 Recommended Draft Policy?  Or should it wait go to the PPM at ARIN 35
 in San Francisco as a Recommended Draft Policy?  What about ARIN free
 pool run-out timing?

 Do you support the policy as written, if not are there any changes
 that could be made that would allow you to support the policy?

 Thanks.

 On 11/25/14, 14:35 , ARIN wrote:
 On 20 November 2014 the ARIN Advisory Council (AC) accepted
 ARIN-prop-213 Modification to CI Pool Size per Section 4.4 as a Draft
 Policy.

 Draft Policy ARIN-2014-21 is below and can be found at:
 https://www.arin.net/policy/proposals/2014_21.html

 You are encouraged to discuss the merits and your concerns of Draft
 Policy 2014-21 on the Public Policy Mailing List.

 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 PDP. Specifically, these principles are:

* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community

 The ARIN Policy Development Process (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,

 Communications and Member Services
 American Registry for 

Re: [arin-ppml] 2014-14, was Internet Fairness

[Andrew Dul]

On 12/26/2014 4:33 PM, Matthew Petach wrote:


 On Fri, Dec 26, 2014 at 3:01 PM, John Springer sprin...@inlandnet.com
 mailto:sprin...@inlandnet.com wrote:

 Hi John,

 Thank you for the clear statement of opposition. Please allow me
 to address the points you offer inline.

 On Wed, 24 Dec 2014, John Santos wrote:


 Oppose 2014-14

 1) /16 is not small


 This has actually been mentioned before, by several commentators.
 The problem with big and not small is that they require
 reference to a datum, which WRT to 2014-14 has not been provided.
 Owen Delong provided a fair attempt to come to grips with what big
 or small actually mean as percentages of the number and size of
 transfers that have occured since the STLS policy was adopted in
 2009, here:




 Hi John,

 I think it might help if we use the terms
 XX-Small, X-Small, Small, etc. as defined
 by ARIN themselves at
  https://www.arin.net/fees/fee_schedule.html

 This might help eliminate confusion, and allow
 for some flexibility going forward; if we instead
 of hard-coding a specific size, instead tie it to
 the fee schedule, and say only entities that
 currently fall into the Small and below category
 of the ARIN fee schedule (ie cumulative /18 or
 less of total IPv4 holdings as of the 2013 fee
 schedule) may obtain a single transfer allocation
 of size not to exceed the largest allowed for an
 XX-Small organization (which, as of the 2013
 fee schedule would mean a /22 or smaller).

 Or perhaps keep it supremely simple:
 Any org-ID may obtain one transfer allocation
 of size not to exceed the largest allocation
 within the XX-Small category (currently a /22,
 as of the 2013 fee schedule) per year without
 requiring needs justification.

 That way, as our concept of ISP size shifts
 and changes over time, so too does the
 maximum needs-free allocation size.

I'm not in favor of linking the fee categories to number policy.  The
fees and its categories are under the control of the board; number
policy is under control of the Internet community via the PDP.  I
believe the board's actions, to adjust fees, should not cause changes
with number policy.

Andrew

___
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-2014-1: Out of Region Use

[Andrew Dul]

Marty,

Can you be a little more specific.  Are you opposed to the whole concept
or the draft as written? 

Do you support the ARIN's current operational practice of excluding
address space, which is in use outside the region, from being considered
utilized when applying for additional allocations?

This was one of the things this policy was attempting to rectify.

I know you support removing all needs requirements, but that isn't the
current policy in this region. 

Andrew

On 12/24/2014 9:03 AM, Martin Hannigan wrote:
 If Ebola were a draft policy it would be this one. Not in favor. 



 On Dec 24, 2014, at 11:50, William Herrin b...@herrin.us wrote:

 On Wed, Dec 24, 2014 at 11:21 AM, ARIN i...@arin.net wrote:
 Policy statement:

 Create new Section X:

 ARIN registered resources may be used outside the ARIN service region. Out
 of region use of IPv4, IPv6, or ASNs are valid justification for additional
 number resources if the applicant is currently using at least the equivalent
 of a /22 of IPv4, /44 of IPv6, or 1 ASN within the ARIN service region,
 respectively.

 The services and facilities used to justify the need for ARIN resources that
 will be used out of region cannot also be used to justify resource requests
 from another RIR. When a request for resources from ARIN is justified by
 need located within another RIR’s service region, the officer of the
 applicant must attest that the same services and facilities have not been
 used as the basis for a resource request in the other region(s). ARIN
 reserves the right to request a listing of all the applicant's number
 holdings in the region(s) of proposed use, but this should happen only when
 there are significant reasons to suspect duplicate requests.
 I think this is bad policy which will encourage registry shopping by
 large multinational companies who really don't need yet another
 advantage over their smaller competitors. Worse than just making ARIN
 a flag-of-convenience registry to the world, it includes just enough
 in-region requirement to shut out small players. I reiterate my
 OPPOSITION to this draft policy.

 Regards,
 Bill Herrin




 -- 
 William Herrin  her...@dirtside.com  b...@herrin.us
 Owner, Dirtside Systems . Web: http://www.dirtside.com/
 May I solve your unusual networking challenges?
 ___
 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.

[arin-ppml] Micro-allocation policy proposal draft

[Andrew Dul]

Hello,

At the Chicago meeting there was some discussion around the
micro-allocation policy (section 4.4) of the NRPM.  I committed to the
AC to produce a draft update to this section based upon feedback that I
heard from the community.  Below you will find a draft update.

This has not yet been submitted to the policy process.  I wanted the
community to validate that they still would like these type of changes
to be considered before formal work on this section started.

I have also attached a PDF redline so that you can easily see the
changes from the current text.

Thanks for your feedback,
Andrew

-

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. Multiple allocations may be granted when
operational need can be documented..

ARIN will place an equivalent of a /16 of IPv4 address space in a
reserve for micro-allocations.

4.4.1 Internet Exchange Points
ARIN will place an additional equivalent of a /16 of IPv4 address space
in a reserve for exchange point allocations under section 4.4.1.  (ARIN
may reserve a block within the last /10 (section 4.10) or from IANA
returned address space (section 10.5) if no other suitable block is
available at the time of policy implementation.)

Exchange point allocations MUST be allocated from specific blocks
reserved only for this purpose. All other micro-allocations WILL be
allocated out of other blocks reserved for micro-allocation purposes.
ARIN will make a list of these blocks publicly available.

Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of
three total), ASN, and contact information. This policy does not
preclude exchange point operators from requesting address space under
other policies.

These allocations will be no smaller than a /26.

4.4.2 gTLD allocations

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 blocks reserved in
section 4.4. This limit of a /23 equivalent per gTLD does not apply to
gTLD allocations made under previous policy.

4.4.3 Other Critical Infrastructure

Other critical infrastructure which is not defined in other sub-sections
of section 4.4, may receive allocations from ARIN, when operational need
can be demonstrated.  These allocations will be no smaller than a /24.



Post IPv4 run-out micro-allocations update.pdf
Description: Adobe PDF document
___
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.