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

[Richard J Letts]

My point of view

a)   I am not sure why educational institutions are not able to pay the 
fees for other categories of usage, or why they need an exception.

ARIN staff would need to decide if the application satisfies this: “a volunteer 
group, not-for-profit, non-profit, or charitable organization”



I’ve been involved with enough community groups to know that two of these have 
weak governance structures that fail when there are conflicts (a volunteer 
group and being a non-core aspect of a charitable organization), inevitably 
leading to the collapse of the organization. I’m not going to prejudge that 
debate here, but consider striking them. If the community organization doesn’t 
have 501(c)3 status in the US they are leaving out the opportunity to save 
money and get grants.



Without a legal entity ‘owning’ the space how would ARIN know they were dealing 
with, who is legally allowed to dispose of the space, etc.



b)  Who cares if they provide ‘other Information Technology services’ to 
their community; we’re talking about internet access here



c)   ‘Persons or entities’ seems redundant (It is like saying ‘people or 
not people’); who/what are the not a person and not an entity that are excluded?



d)  I am not sure what is considered critical? Digging ditches? Pulling 
fiber? Responding to ARIN requests? Filing forms with the IRS?

As an example I’m on the board of a non-profit. We decide on the aims, manage 
the membership, etc. but we pay [independent 1099] contractors for services 
(editing and printing the newsletter, performing at concerts, concert sound, 
etc.). Some of these are non-critical (the newsletter), some are critical (the 
performers), volunteers some critical things (IRS tax returns, state 
registrations) and some non-critical things (run the website)

So I think I end up with something with fewer words.

“A community network is a network organized and operated by a volunteer group, 
not-for-profit, non-profit, or charitable organization

 for the purpose of providing free or low-cost connectivity within their 
community. Volunteers play a large role in directing the activity of the 
organization, but some functions may be handled by paid staff.”


/RjL




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


___
PPML
You are receiving this 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-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

[Richard J Letts]

On this thread we've gone from near-real-time update of bus GPS co-ordinates to 
suggesting allocating over 64 subnets per student for most of our school 
districts was a bad idea and we should have allocated more(!)

Some stats for SY2017   # districts: 317; # districts <=100 students: 46  ; 
# districts <=1000 students: 173 (including the 46)  ; # districts >= 10,000: 
33 (source: http://www.k12.wa.us/DataAdmin/enrollment.aspx)
Initial allocations have been around for more than 7 years. In 7+ years no 
school district has come back and asked for more or a larger allocation than a 
/48.

I'm going to point out the current policy supports how we're swiping address 
space and it's up to you to persuade me your change is worthwhile. 

Richard


___
PPML
You are receiving this 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-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

[Richard J Letts]

I believe we should SWIP for /48.
I believe we may SWIP for /56 or longer if the Service provider deems it 
useful. 

As an example we assign /48's to school districts, colleges, and universities 
in the State of Washington. I want each of them to have their own SWIP records 
so any issues with traffic originating from the site can get addressed by the 
local network administrators before they get escalated up to me as the WA-K20 
NOC manager.
We do not advertise separate routing for most of these /48 -- I do not want any 
linkage between SWIP and routing.
Stating SWIP is not required for /48 leaves me open to them asking me not to 
SWIP (for some reason), and it is absolutely not the same as /32 SWIP in v4.

Thank you

Richard Letts
Manager: Network Operations Center: WA-K20, UW, UW Medicine, PNWGP, PWAVE, WRN

> -Original Message-
> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of
> hostmas...@uneedus.com
> Sent: Thursday, July 27, 2017 10:10 AM
> To: arin-ppml@arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment
> Registration requirements between IPv4 and IPv6 - updated 2017-07-21
> 
> I agree that we need to act on THIS draft, and not load up the discussion with
> other issues that this draft is not intended to address.  The one question
> regarding SWIP/WHOIS policy in general I have moved to another thread
> since it is unrelated to this draft.
> 
> This draft is about changing the Assignment Registration rules to allow
> minimum static assigments of IPv6 space to be made most of the time
> without triggering a SWIP requirement.  Current policy is effectively 100%
> registration, which is not true for the same customer using IPv4.
> 
> After discussing changing the standard from /64 to /60 or /56, we appear to
> have agreed that the end user site minimum assignment should be /48, and
> that operators should not be assigning less.
> 
> The last draft has language that I understood to have the effect of:
> 
> *  /47 or more MUST SWIP, as these sizes are larger than an end user.
> 
> * Any size that is separately routed, which under most routing policies would
> be a /48 or larger, shall also SWIP.  This also leaves the decision as to what
> level is routed to others, as this is not an ARIN decision.
> 
> *  Otherwise SWIP is not required for a /48, as this size is the basic end 
> user
> or site assignment, similar to demanding /32 SWIP's in v4.
> 
> There has also been some discussion that the current draft language does
> not reflect the above concepts, and suggesting changes. These are in scope.
> However problems with SWIP, WHOIS, abuse, etc are not in scope for this
> draft, and are not helpful in deciding what we need to have in this draft.  If
> there are others that seek to fix these other issues, lets have them propose
> a different draft to do so, rather than trying to insert that here into this 
> one.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> On Thu, 27 Jul 2017, Jason Schiller wrote:
> >
> > three points:
> > 1. This proposal is not trying to address the problem of how ISPs
> > handle abuse.
> >
> > If that is a problem the community wants to tackle, lets define the
> > problem and propose policy in a DIFFERENT proposal
> >
> > 2. I do not believe the suggested changes impact how ISPs handle abuse.
> >
> > How ISPs handle abuse is orthogonal  to this proposal.
> >
> > 3. How ISPs handle abuse is complicated and opaque and requires more
> > nuance and clarity about what is actually required for compliance.
> >
> >
> > As is said before compliance tends to be very good when it is either
> > required, or beneficial to the organization.
> >
> >
> > If an organization is trying in good faith, to follow ARIN rules, then
> > they will try to keep SWIP information for their networks accurate, as
> > well as for their down stream customers.
> >
> > There is no ARIN requirement that a provider need to process or
> > respond to abuse complaints on their network space, nor that they take
> > action on downstream customers who fail to process  abuse complaints.
> >
> > In some cases their are particular legal rules in particular countries
> > that some types of abuse complaints are required to be processed, for
> > example legal take down requests. I suspect you will find very high
> > compliance in processing these types of abuse complaints.
> >
> > In other cases there are unwritten standards of conduct that when
> > violated results in a TOS agreement violation leading to loss of
> > service.  I suspect you will find a wide mix in terms of what is
> > permitted under various TOS (although generally it is expected that
> > the requirements are at least as strict for down stream
> > customers)
> > as well as a wide mix on level of compliance in processing TOS abuse
> > complaints.
> >
> > In yet other cases, media agreements will contractually require DMCA
> > violations to be processed.  These are often 

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

[Richard J Letts]

I have too many roles and job-titles, so below is my opinion only (as I'm at 
lunch right now)

My 2c.

As a residential customer with IPv6:
There are many valid reasons not to expose individual residential customer 
addresses. For example someone being stalked or harassed by an ex. If their 
IPv6 address is exposed in any way that leads someone too easily back to them 
then that is not a good thing. I feel that the length should mirror what is 
implicitly provided for ipv4 because the customer expectation has some 
importance here. 
I'm going to note that Comcast is currently handing out /60 to residential 
customers. 
Therefore I think swipping:
/60 & smaller : Bad idea (does not provide the same _implicit_ privacy 
that IPv4 does)
/56: maybe if that's your default assignment block
/52: maybe if that's your default assignment block
/48: should be required.

I'm also going to note that with IPv6 I can have multiple IPv6 addresses from 
different providers if I am simply multi-homed (i.e. not exchanging routing 
information). 

As a NOC manager:
I find SWIP records occasionally useful for reaching people I need to when 
discussing routing or abuse issues. It's not often but they are useful when 
they are there.
For the WA-State K20 network we do our best to ensure that we have these 
correctly published so people can reach the right contacts on that network (we 
are not always told when contacts leave)

I find SWIP records a pain to manage, but given I find them useful I'm quite 
happy to publish them as a help to the community.
It's as easy to SWIP a /56 as a /48 if I'm already doing the /48 -- it's all 
just database updates and a SMOP. Anyone getting a /56 or /48 isn't likely to 
be a residential customer.
(note: WA-K20 State network default assignment is a /48 -- but that's not 
relevant to the point here)
Business are generally required to have registered address for communications, 
they can always use that for their registration.



Richard Letts
Manager: Network Operations Center: UW, UW Medicine, WA-K20, PNWGP, 
PacificWave, WRN
Process Manager: Incident Management, Event Management
Service Manager: Wired Network Service
UW Information Technology
Mail: Box 354840
Street: 4545 15th Ave NE, Seattle, WA, 98105
206.685.1699 | mobile 206.790.5837
rjle...@uw.edu


___
PPML
You are receiving this 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-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Richard J Letts]

Specifically: DMCA violation notices go to the SWIPed contacts instead of the 
original holder.

/RjL



From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of Martin Hannigan
Sent: Wednesday, May 31, 2017 7:58 PM
To: Seth Mattinen ; arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment 
Registration requirements between IPv4 and IPv6



Someone want to remind us all of what the "benefits" of SWIP are?

Best,

-M<

___
PPML
You are receiving this 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

[Richard J. Letts]

> -Original Message-
> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of Andrew Dul
> Sent: Tuesday, February 14, 2017 6:40 PM
> 
> 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?

a) Yes; in particular the 'abuse' and 'noc' contacts which are often used for 
receiving DCMA complaints

b) If they are not accurate then the ISP receives the complaints and are 
motivated to get the re-assignment records out there.
However they do not necessarily need to be fully accurate. For example I'm not 
sure ARIN has ever validated the name of some of the POC.
(e.g. if an organization has renamed itself from Networks and Distributed 
Systems, to Computing and Communications, and then to Information Technology 
that's not validated and doesn't need to be accurate for communication to occur)

c) No idea what you're getting at with the last part of this question

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

the organization doing the re-assignment

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

The area where we publish the most reassignment records is for the state 
education network -- I think the need and opportunity to acquire additional 
IPv4 address space for that network has probably passed. (The network's fully 
IPv6 enabled, most school districts have NAT and firewalls). So there's 
little/no value in publishing these records JUST for ARIN to determine 
utilization as [today] I'm unlikely to need them for that purpose.

> 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?
No -- not by ARIN anyway given my belief that the organization performing the 
re-assignment ought to be responsible for maintaining the records of their 
customers properly.


> 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?
No -- but then we have a well-defined customer base that hardly changes so it's 
not as if we're adding random people at an organization.

My 2cents

Richard Letts
___
PPML
You are receiving this 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] Revisit RPKI TAL Relying Party Agreement?

[Richard J. Letts]

From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of William Herrin
> Sent: Friday, February 3, 2017 9:29 AM
...
> Exactly. You refuse to provide new services related to legacy resource
> holdings, including RPKI. While not unreasonable in the context of ARIN
> operations, this is harmful to the RPKI efforts. This is something no
> organization prioritizing RPKI would do. Since offering new services like RPKI
> to legacy registrants* appears inimical to ARIN's core mission I respectfully
> question whether ARIN can be a satisfactory steward for RPKI.

RIPE's Policy is:
The resource certificate is linked to RIPE NCC registration. This is because 
only for as long as you are a RIPE NCC member and *have a contractual 
relationship with the RIPE NCC* can it be authoritatively stated who the holder 
of a certain Internet number resource is. 

 [Emphasis mine]

It doesn't seem to that different from what I understand ARIN's policy is.

___
PPML
You are receiving this 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] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

[Richard J. Letts]

That is a question for ARIN staff to weigh in on.
What “independently verifiable evidence” would be acceptable if no assets (I 
assume this means servers or routers rather than human beings) using the 
resources are being moved?

Richard

From: Scott Leibrand [mailto:scottleibr...@gmail.com]
Sent: Tuesday, January 24, 2017 4:13 PM
To: Richard J. Letts <rjle...@uw.edu>
Cc: arin-ppml@arin.net
Subject: Re: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - 
Text modifications

Wouldn't the existing language ("The recipient must provide independently 
verifiable evidence that they have acquired the assets that use the resources 
to be transferred from the current registrant.") be good enough for those 
scenarios?  The additional OR clause seems mostly meant to deal with defunct 
entities where the assets that use the resources are long gone, and all that's 
left is the original corporate entity.  Are there any cases in the government 
realm where that is a problem as well, and M transfers can't be completed 
under the existing rules?

-Scott

On Tue, Jan 24, 2017 at 3:59 PM, Richard J. Letts 
<rjle...@uw.edu<mailto:rjle...@uw.edu>> wrote:
This assumes that only corporate entities merge, acquire, or re-organize. How 
would state agencies or an inter-institution research group produce the 
required documentation to facilitate the movement of resources given the lack 
of independently verifiable information?

Similarly, a function might be transferred between state agencies, but we might 
not be acquiring an entire corporate entity (as we’re a state agency).

Richard

From: ARIN-PPML <arin-ppml-boun...@arin.net<mailto:arin-ppml-boun...@arin.net>> 
on behalf of John Springer <3jo...@gmail.com<mailto:3jo...@gmail.com>>
Date: Tuesday, January 24, 2017 at 12:32 PM
To: "arin-ppml@arin.net<mailto:arin-ppml@arin.net>" 
<arin-ppml@arin.net<mailto:arin-ppml@arin.net>>
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text 
modifications

These two changes will leave Section 8.2 looking like this:
8.2. Mergers and Acquisitions
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.
AND one or more of the following:
The recipient must provide independently verifiable evidence that they have 
acquired the assets that use the resources to be transferred from the current 
registrant.
OR
The recipient must show that they have acquired the entire corporate entity 
which is the current registrant.


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

___
PPML
You are receiving this 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] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

[Richard J. Letts]

This assumes that only corporate entities merge, acquire, or re-organize. How 
would state agencies or an inter-institution research group produce the 
required documentation to facilitate the movement of resources given the lack 
of independently verifiable information?

Similarly, a function might be transferred between state agencies, but we might 
not be acquiring an entire corporate entity (as we’re a state agency).

Richard

From: ARIN-PPML  on behalf of John Springer 
<3jo...@gmail.com>
Date: Tuesday, January 24, 2017 at 12:32 PM
To: "arin-ppml@arin.net" 
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text 
modifications

These two changes will leave Section 8.2 looking like this:
8.2. Mergers and Acquisitions
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.
AND one or more of the following:
The recipient must provide independently verifiable evidence that they have 
acquired the assets that use the resources to be transferred from the current 
registrant.
OR
The recipient must show that they have acquired the entire corporate entity 
which is the current registrant.

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

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

[Richard J. Letts]

Following Owen's opposition to this I decided to have a look.

This is probably not relevant to many of my users so I'd not looked in detail 
at this.

I'm going to note that the NRPM is improperly called the Number Policy Resource 
Manual on the first line of the problem statement, which makes me wonder how 
many other errors there are in the rest of the document, or how closely this 
has been read by others?

I'm bothered by a proposal that has a problem statement

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

And then goes on to to
"Therefore, we propose the following rewrite of the transfer policy,  section 8 
of the NRPM."
If section 4 is not relevant, then modify that, and not section 8

8.2: 
What incentive do I have for doing this? i.e. transferring assets between  
entities.
Ah! it allows though M for entities to accumulate more resources than they 
would otherwise be able to. 
And provides no enforcement for the return of resources.
Hmmm... looks like a problem to me.

The other sections then exclude resources acquired through M activities from 
evaluation.
If I had looked at this previously I would have removed 'This  restriction does 
not include M transfers.' From 8.3-8.5

So, I'm going to come down as opposed to this.

Richard Letts

> -Original Message-
> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
> Behalf Of ARIN
> Sent: Wednesday, October 26, 2016 2:17 PM
> To: arin-ppml@arin.net
> Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-5:
> Post-IPv4-Free-Pool-Depletion Transfer Policy
> 
> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send
> Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion
> Transfer Policy to Last Call:
> 
> The AC provided the following statement to the community:
> 
> This proposal is technically sound, fair, and impartial in that it 
> establishes a
> new set of qualifying criteria for 8.3 and 8.4 transfers applicable to all
> requests. It is strongly supported by the community.
> 
> Feedback is encouraged during the Last Call period. All comments should be
> provided to the Public Policy Mailing List. This Last Call will expire on 9
> November 2016. After Last Call, the AC will conduct their Last Call review.
> 
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
> 
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion
> Transfer Policy
> 
> AC's assessment of conformance with the Principles of Internet Number
> Resource Policy:
> 
> 2016-5 is one of a set of overlapping policies involving simplification of 
> section
> 8 specified transfer policy. Each takes a somewhat different approach, and all
> have a degree of community support. Based on community feedback at the
> upcoming ARIN 38 meeting in Dallas, we hope to advance whichever of those
> proposals is best-supported by the community, or craft and advance a
> unified proposal that incorporates the best attributes of the proposals
> currently on the docket. Moving 2016-5 to Recommended Draft will facilitate
> moving the best policy forward in a timely manner.
> 
> 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
> 
> 

Re: [arin-ppml] Community Networks (Was Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM)

[Richard J. Letts]

6.5.9.1 says more than was quoted.

The bit that was missing is "For community networks located in rural regions 
(population less than 2,500) or in the Caribbean and North Atlantic Islands 
Sector, the numbers in these qualification criteria may be relaxed at ARIN's 
discretion."

More than half of the 'cities' (55% to be exact) in the State of Washington 
have populations less than 2500 people -- so if the 50/100 was really an 
impediment an applicant/ARIN has a way out of it.

This is somewhat beside the point: I'm all for getting rid of inapplicable 
sections of the NPRM and the HD-ratio seems to be one of them

/RjL

> -Original Message-
> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On 
> Behalf Of David R Huberman
> 
> Hi Keith,
> 
> Thanks for the reply.
> 
> My understanding from the community network presentations given to the
> ARIN community was that the 50 assignments / 100 assignments thresholds
> were too high a bar to clear.  I believe they said that commonly, community
> networks are often considerably smaller, connecting small groups of
> participants in a co-operative, zero revenue model.
> 
> I'll see if I can dig up the foils in the ARIN archives (it was a few years 
> ago
> now), and confirm if my memory is accurate.  Or if someone who has
> experience with typical community network architecture is on-list and could
> reply, that'd be even better :)
> 
> David
> 
> 
> 
> > David,
> >
> > 6.5.2.2 item C requests a plan “with a minimum of 50 assignments within 5
> years”
> >
> > 6.5.9.1 says “a community network must demonstrate it will immediately
> provide sustained service to at least 100 simultaneous users and must
> demonstrate a plan to provide sustained service to at least 200 simultaneous
> users within one year.”
> >
> > Seems to me that it would be easier to create a plan for 50 assignments
> within 5 years than demonstrate providing service to at least 100
> simultaneous users immediately.
> >
> > I suppose the reason no one has requested IP space under the community
> networks proposal could be that it seems to only apply to IPv6, and there
> does not yet seem to be a large end-user demand for IPv6 connectivity. Or
> perhaps removing the HD-ratio will simplify the community network section
> enough that it will get used.
> >
> > Keith
> >
> >
> > From: David Huberman [mailto:dav...@panix.com]
> > Sent: Tuesday, August 9, 2016 6:09 PM
> > To: Keith W. Hare 
> > Cc: David Farmer ; arin-ppml@arin.net
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2016-6: Eliminate HD-Ratio
> > from NRPM
> >
> > Keith,
> >
> >
> > Which criterion in 6.5.2.2 (ISP initial) would a small community network
> qualify under? Or 6.5.8.1 (end user initial)?
> >
> > Answer: it's been proven by the community networks folks that in many
> > cases a requisite couldn't meet any of those criteria. They need
> > special language, and got it. :-)
> >
> >
> >
> > On Aug 9, 2016, at 2:59 PM, Keith W. Hare
> > wrote:
> > From a quick read of the Community Networks section, I don’t see where
> someone saves anything by qualifying as a Community Network.
> >
> > So, I support draft policy 2016-6 as written, but would also support a
> proposal that completely eliminates the Community Networks sections.
> >
> > Keith
> >
> >
> > Keith W. Hare
> > ke...@jcc.com
> > JCC Consulting, Inc.
> > 600 Newark Granville Road
> > P.O. Box 381
> > Granville, Ohio 43023 USA
> > Phone: +1 740-587-0157
> > http://www.jcc.com
> >
> >
> >
> >
> > From: arin-ppml-boun...@arin.net
> > [mailto:arin-ppml-boun...@arin.net] On Behalf Of David Farmer
> > Sent: Monday, August 8, 2016 11:14 PM
> > To: arin-ppml@arin.net
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2016-6: Eliminate HD-Ratio
> > from NRPM
> >
> > As AC Shepherd, I haven't seen much discussions of this one;  I think the
> Elimination of HD-Ratio is probably fairly non-controversial itself.
> >
> > However, in regards to the Community Networks section, I see three
> > high-level alternatives for the community to consider;
> >
> >   1. Rewrite the Community Networks section to not reference HD-Ratio, as
> the Draft Policy suggests;
> >   2. Replace the Community Networks section with a generic small ISP policy
> allowing allocations of /40 (qualifying for xxx-small IPv6 fee category);
> >   3. Remove the Community Networks section all together; It doesn't
> > seem to have been used since it was adopted, see Dan Alexander's
> > Policy Simplification presentation, slide #4. If we go this way, 2.11
> > should be deleted also;
> >
> >
> https://www.arin.net/vault/participate/meetings/reports/ARIN_37/PDF/tu
> > esday/alexander_simplification.pdf#page=4
> >
> > I think a rewrite in line with the original intent for the Community 
> > Networks
> section is the proper place to start the conversation, and I 

Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy

[Richard J. Letts]

My preference is to apply the policy change as written (with the minor 
editorial change substituting "criterion" for "criteria".)

Thank you
Richard Letts

> -Original Message-
> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
> Behalf Of David Farmer
> Sent: Monday, February 15, 2016 9:23 PM
> To: ARIN PPML 
> Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization
> Requirement in End-User IPv4 Policy
> 
> As shepherd, I need additional feedback on this, I need a better sense of
> what the community wants here.
> 
> Should we move forward more or less as-is, with a minor editorial change,
> substituting "criterion" for "criteria"?
> 
> Or, does the community want to work on a way to address the concerns
> raised but Jason?
> 
> Your input please.
> 
> Thanks
> 
> On 1/29/16 10:00 , 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
> 

Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy

[Richard J. Letts]

Why are we adding more rules  for IPv4 space?


a)   It is almost impossible to get space in a reasonable timescale without 
paying (more than just the ARIN fees) for it

b)  If you have to pay for the space anyway you are not going to buy 
something that you can't use (unless you are speculating), and I think a /16 
goes for over half a million..

c)   If you are giving public IP address to 64K new PC's then rationally 
asking why you are not putting them being a NAT appliance and giving you a /24 
is a good question

A NAT appliance can be had for well less than half a million...

(if you are deploying 64K new servers the same applies, except we're talking 
about a load balancer there)

Let's simply get rid of the 25% in 30 days and worry about IPv6 transition.

I feel that every time we make the rules more complex we increase the costs for 
managing requests and those are /not/ borne by the requestor (until they 
acquire space)
This is unfair on the small organizations with LRSA who already have their 
space and make almost no call on ARIN's services.
I.e. the $100/record/year fee when there are no actual changes and there cannot 
possibly be a $100 worth of power used in preserving each record

Thank you
Richard Letts
___
PPML
You are receiving this 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] Advisory Council Meeting Results - December 2015

[Richard J. Letts]

As an alternative to ARIN taking on the burden of allowing/managing SWIP for 
end-user registrants how about allowing end-user registrants to register/run a 
rwhois server?

That way if a large organization (like, say Apple or Microsoft) wants to 
publish data for their networks they can take on all the server costs and 
managing the data without imposing significant additional costs on ARIN?

Would that meet the need?

Richard Letts

From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf 
Of David Huberman
Sent: Tuesday, December 22, 2015 11:45 AM
To: arin-ppml@arin.net
Subject: Re: [arin-ppml] Advisory Council Meeting Results - December 2015

Following the excellent example that Scott Leibrand has done over the years, I 
wish to convey my objections over the abandonment of 2015-8, which would allow 
End-users to SWIP.

Year after year, and issue after issue, John Curran tells us "this is the way 
we are doing it; if you want us to change, go propose a policy".

That's exactly what happened with 2015-8.

The issue is complex because of the billing issues (most of the justification 
for the original ISP fee schedule was because of SWIP) and the existence of the 
dichotomy between ISPs and EUs.

But the proposal is sound, in my opinion.  It introduces a policy requirement 
to force ARIN to change how it runs its software.  There's no wiggle room when 
a policy like this is passed.  The community speaks, the staff carries it out.

I acknowledge that there was not tremendous support at the first public meeting 
for 2015-8, but I think that is insufficient cause to abandon it.  We should 
discuss it further.

It should not be abdicated to the services WG which is not an elected body.

David

Sent from Outlook Mobile



On Tue, Dec 22, 2015 at 11:26 AM -0800, "ARIN" 
> wrote:
In accordance with the ARIN Policy Development Process (PDP), the ARIN
Advisory Council (AC) met on 17 December 2015.

Having found the following Draft Policy to be fully developed and
meeting ARIN's Principles of Internet Number Resource Policy, the AC
recommended it for adoption (to be posted separately for discussion as a
Recommended Draft Policy):

   Draft Policy ARIN-2015-11: Remove transfer language which only
applied pre-exhaustion of IPv4 pool

The AC abandoned the following:

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

The AC provided the following statement, "The ARIN AC has voted to
abandon draft proposal ARIN-2015-8. Although a number of participants at
ARIN 36 and on the PPML indicated support for investigation of greater
harmonization of the services provided by ARIN to ISPs and End-Users,
this specific proposal had no substantial community
support. In fact, those who addressed themselves to the specific
proposal, rather than broader issue of fees charged to ISPs vs.
End-users or the types of services that ARIN should provide to each
class of clients, did not support the specific proposal itself. Based on
community feedback, we would suggest the broader issues be considered by
ARIN, as part of a review of services."

The AC is continuing to work on:

   Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to
Specified Recipients)
   Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in
end-user IPv4 policy
   Recommended Draft Policy ARIN-2015-5: Out of region use
   Draft Policy ARIN-2015-6: Transfers and Multi-national Networks
   Draft Policy ARIN-2015-7: Simplified requirements for demonstrated
need for IPv4 transfers
   Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for
Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks

The AC abandoned 2015-8. Anyone dissatisfied with this decision may
initiate a petition. The deadline to begin a petition will be five
business days after the AC's draft meeting minutes are published. For
more information on starting and participating in petitions, see PDP
Petitions at:
https://www.arin.net/policy/pdp_petitions.html

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
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:
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:

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

[Richard J. Letts]

Where did the 9% come from? Should that not be 24%?

Either way, if we were talking about houses then many of us realize that if the 
number of bidders on property who had the cash (but not the need) were 10 or 
25% larger, then you might expect the value of the property to be higher. The 
same is true with any inelastic good. I have no idea what the price elasticity 
of IP address space is, but I’m going to suggest that it’s very inelastic given 
the lack of alternatives (IPv6 is an alternative, but it has other costs 
associated with it)

I have not seen an argument that this policy will not increase the price of 
IPv4 addresses for people who have needs, and I can’t see that is a good thing.

Richard Letts


From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf 
Of John Curran
Sent: 30 September 2015 12:29 PM
To: Dani Roisman 
Cc: arin-ppml@arin.net
Subject: 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

On Sep 30, 2015, at 1:15 PM, John Curran 
> wrote:

Unfortunately, we do not have any readily-available way to correlate the
not-completed tickets with intended block size.  We do have overall
transfer ticket closure statistics available.

8.3 / 8.2 Ticket statistics to date -

153  8.3 tickets closed
106  completed (69%)
  37  withdrawn (24%)
4  duplicate (3%)
3  abandoned (2%)
3  closed for another reason (2%)

   82 8.2 tickets closed
   68 completed (83%)
   12 withdrawn (15%)
 1 duplicate (1%)
 1 other (1%)

If one presumes that demonstration of need is a more significant concern
for 8.3 transfers (generalization, but plausible) _and_ that there was no
other significant factor (lots of hand-waving at this point), then there is a
9% withdrawal rate (and potentially 2% abandoned rate)  that one might
bravely attribute to the consequences of needs-assessment.

/John

John Curran
President and CEO
ARIN

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

Re: [arin-ppml] 11 Proposals Under Consideration

[Richard J. Letts]

Dave Farmer asked for opinions on the other proposals.

-9 has been flogged close to death, here are my opinions on five of the others.

> -Original Message-
> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
> Behalf Of David Farmer
> Sent: 25 September 2015 2:14 PM
> To: ARIN PPML 
> Subject: [arin-ppml] 11 Proposals Under Consideration
> 
> There are currently 11 proposals under various stages of consideration and
> development in the ARIN Policy Development Process;
> 
> >   Recommended Draft Policy ARIN-2015-1: Modification to Criteria for
> IPv6 Initial End-User Assignments
Looks good, expands IPv6

> >   Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in
> end-user IPv4 policy
OK, really reasonable. ARIN staff comments on this one should be implemented as 
well.

> >   Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better
> reflect how ARIN handles reorganizations
OK


Taking these two together:
> >   Draft Policy ARIN-2015-5: Out of region use
> >   Draft Policy ARIN-2015-6: Transfers and Multi-national Networks
I'm not a fan of either of these, they only address a small number of 
organizations, and potentially could be solved by obtaining address space in 
the right RIR and renumbering the out of ARIN RIR locations, and seem to have a 
higher burden on ARIN staff to implement. Can policies suggest that additional 
fees be levied against organizations specifying out of region use, Transfers, 
or Multi-national Networks?

Part of me feels like we should stop wasting resources trying to update IPv4 
policies unless they are obviously broken for almost every organization and 
make sure the barriers to IPv6 are low.

Richard Letts
___
PPML
You are receiving this 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-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks

[Richard J. Letts]

b) 
There is no definitive outcome from the policy change, which makes me feel that 
it's not worth changing -- the problem statement argument is weak at best.

It is potentially enabling organizations with more money than need gain more 
resources, potentially at the expense of non-profit and educational 
organizations who might not be able to raise cash for additional IPv4 space [or 
equipment to support a transition to IPv6]. Changing policy just to 
(potentially) improve the accuracy of a database seems not worth the 
(potential) risk.

Richard



From: arin-ppml-boun...@arin.net  on behalf of Dani 
Roisman 
Sent: Thursday, September 24, 2015 6:20 PM
To: arin-ppml@arin.net
Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based 
evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks

| Date: Wed, 23 Sep 2015 16:53:59 -0400
| From: ARIN 
| To: arin-ppml@arin.net
| Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based
|   evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks
| Message-ID: <56031167.1010...@arin.net>
| Content-Type: text/plain; charset=utf-8; format=flowed
|
| Draft Policy ARIN-2015-9
| Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4
| transfers of IPv4 netblocks
|
| On 17 September 2015 the ARIN Advisory Council (AC) accepted
| "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3,
| and 8.4 transfers of IPv4 netblocks" as a Draft Policy.
|
| Draft Policy ARIN-2015-9 is below and can be found at:
| https://www.arin.net/policy/proposals/2015_9.html

Greetings,

There has been some stimulating dialog about the merits of 2015-9.  I'd like to 
ask that in addition to any overall support or lack thereof, you also review 
the policy language and comment specifically on the changes proposed:
a) For those of you generally in support of this effort, are there any 
refinements to the changes made which you think will improve this should these 
policy changes be implemented?
b) For those of you generally opposed to this effort, are there any adjustments 
to the policy changes which, if implemented, would gain your support?

--
Dani Roisman
___
PPML
You are receiving this 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] ARIN-PPML 2015-2

[Richard J. Letts]

If that is the case, then ARIN/We should update inter-RIR policies to only 
allow transfers to registries that have substantially similar transfer 
policies. This does not require complete blobal co-ordination, but it will 
establish areas where co-operating RIRs get access to free markets and 
uncooperative RIRs do not.

If target registry does not allow transfers out of their RIR then
reject transfer to target registry
If target registry allows transfers out of their RIR to any other registry that 
does not allow transfers out of their RIR then
reject transfer to target registry
else
accept the transfer

Otherwise you have the situation where limited addresses cannot be transferred 
across border, leading to an imperfect market which (long-term) affects the 
rest of the world’s ability to function using IPv4 (which will be significant 
for a while yet)

In the meantime, making it harder to move recently acquired addresses to a 
different RIR acts as a brake on the ability to arbitrage or move relatively 
recently acquired addresses to a registry with restrictive market policies.

Richard Letts

From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf 
Of Rocky
Sent: 4 June 2015 6:24 PM
To: b...@herrin.us
Cc: arin-ppml@arin.net
Subject: Re: [arin-ppml] ARIN-PPML 2015-2

Hi William,

Same as the CNNIC,   KRNIC, VINNIC, IDNIC and NIXI ( Indian NIR) do not allow 
to transfer their IPv4 addresses out of their NIRs.


___
PPML
You are receiving this 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] 2015-2

[Richard J. Letts]

I am against 2015-2; either I’m not understanding why waiting to do this is a 
problem or it’s shuffling deckchairs for a minority of companies.

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

Re: [arin-ppml] IPv6 End-User Initial Assignment Policy (or: Please don't me make do ULA + NAT66)

[Richard J. Letts]

I have read the scenarios people have presented and I have not understood what 
the problem statement is.
Has anyone asked and failed to get IPv6 resources?

It looks to me like the problem statements are for really small businesses and 
caused by poor network design, or the assumption that having *both* ULA and 
global IPv6 addresses on the same host is going to be a problem.
e.g. why not use ULA internally on a network for internal resources, use 
provider-based RA assignments for external connectivity. Then you only have to 
manage site-to-site VPN connections for the ULA networks.
Switching external providers is a matter of updating router configs (adding new 
subnets to interfaces), and reconfiguring the sitesite VPN tunnels (all of 
which should be in the same engineering management domain), and NOT 
reconfiguring 126 hosts.

[business with 62-126 or more IPv4 addresses should be able to obtain at least 
one /24 of public IPv4 space and then apply for IPv6 space under 6.5.8.1(a)]

If you've a vendorcustomer VPN connection then that's a specific technical 
challenge -- I have several of these and they are *all* engineered differently 
and break in their own unique ways. I don't think it's possible to write a 
generic policy that covers what's needed to get these to work except 6.5.8.1(e) 
would appear to me to be the policy to apply for space under. 
Has anyone failed to get space under that section?

Having justified the initial assignment criteria the initial assignment size is 
independent and the business should get sufficient space to cover the number of 
sites under 6.5.8.2

Like I said, I feel I'm not understanding if this is a real problem where 
businesses have actually been denied IPv6 address space?

Richard Letts
___
PPML
You are receiving this 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] Multi-homing justification removed?

[Richard J. Letts]

I believe the intent was there.

orgs that have a justifiable/provable need for a /24 were been restricted by 
their current/lone provider being unwilling to give them enough address space. 
Not everyone has the ability to change providers, and if you can't change 
providers then you certainly would not be able to multihome..

Richard Letts


From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf 
Of Steve King
Sent: Wednesday, November 19, 2014 9:47 AM
To: arin-ppml@arin.net
Subject: [arin-ppml] Multi-homing justification removed?

The changes implemented in ARIN-2014-13, specifically the removal of 4.3.2.2, 
appear to have removed the multi-homing justification for a /24 for end users.  
Previously, the need to multi-home, and proof of contracts with multiple 
upstream providers, was sufficient to justify a /24 to participate in BGP.

For reassignments from ISPs, the language remains in 4.2.3.6.  Users can 
justify a /24 via a requirement to multi-home rather than utilization rate.  
However this revision appears to leave utilization rate as the only criterion 
for direct end-user assignments.

Was this the intent or possibly an overlooked side effect of the change?



Steve King
ICON Aircraft

___
PPML
You are receiving this 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-18: Simplifying Minimum Allocations and Assignments

[Richard J. Letts]

What Seth said; oppose 2014-18

/RjL

 
On Wed, 3 Sep 2014, Seth Mattinen wrote:
 
  On 7/23/14, 7:58, ARIN wrote:
   On 17 July 2014 the ARIN Advisory Council (AC) accepted
   ARIN-prop-210 Simplifying Minimum Allocations and Assignments as a
 Draft Policy.
  
   Draft Policy ARIN-2014-18 is below and can be found at:
   https://www.arin.net/policy/proposals/2014_18.html
  
   You are encouraged to discuss the merits and your concerns of Draft
   Policy 2014-18 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-2014-18
   Simplifying Minimum Allocations and Assignments
 
 
  I completely oppose this policy.
 
  If an org of any size it too lazy or ineffective to bother with
  planning to justify a /24 then they can get a /29 or whatever from an
  ISP that doesn't need justification. They don't need IP space from ARIN.
 
  Justifying a /24 is a very low bar. Either do it or go home.
 
  ~Seth
___
PPML
You are receiving this 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] Policy discussion - Method of calculating utilization

[Richard J. Letts]

 -Original Message-
 From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
 Behalf Of Jeffrey Lyon
 Sent: Wednesday, April 30, 2014 7:49 AM
 
 Friends, Colleagues,
 
 A couple of years ago I brought up an issue I had run into where the
 utilization requirement for new requests is being calculated on a per
 allocation basis rather than in aggregate. For example, if an organization
 has 4 x /22 and 3 of them are utilized 100% and the fourth utilized at
 75%, that request would be denied. This is a bit out of balance as an
 organization with a single /20 utilized at 80% would have less efficient
 utilization but would be eligible to request additional space.
 
 The last time this was discussed it sounded as if the community would
 support a policy proposal to change this calculation to be considered in
 aggregate vs. per assignment. Does this remain the case?

In the current policy legacy assignments are implicitly excluded from this 
calculation.
Would they be excluded or included in your aggregate suggestion?

In the case of large or multinational organizations, how far would you 
aggregate?
e.g. All Microsoft divisions, spanning RIRs; Comcast all markets? 

Richard Letts
___
PPML
You are receiving this 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] Policy Proposal: Reduce all Minimum Allocation/Assignment units to /24

[Richard J. Letts]

Support.

4.9/4.9.1 could be deleted; ARIN would then need no special handling for that 
part of the region.

Richard Letts
Network Operations Center Manager
UW Information Technology
Mail: Box 354840
Street: 4545 15th Ave NE, Seattle, WA, 98105
206.685.1699 | mobile 206.790.5837
rjle...@uw.edumailto:rjle...@uw.edu

On Tue, Apr 29, 2014 at 10:58 AM, Owen DeLong 
o...@delong.commailto:o...@delong.com wrote:

Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0



 1.  Policy Proposal Name: Reduce all Minimum Allocation/Assignment 
units to /24

 2.  Proposal Originator

 a.  name: Owen DeLong

 b.  email: o...@delong.commailto:o...@delong.com

 c.  telephone: 408-890-7992tel:408-890-7992

 d.  organization: Hurricane Electric

 3.  Date: 29 April, 2014

 4.  Problem Statement:

As we approach runout, more and more end users and smaller ISPs will be unable 
to obtain space from their upstreams and will be seeking space from ARIN. In 
order to meet these needs to the extent possible and to make policy more fair 
to a broader range of the ARIN constituency, we should reduce the minimum 
assignment and allocation units to /24 across the board.

 5.  Policy statement:

Change the minimum allocation and assignment unit for all IPv4 single and multi 
homed instances to /20. This would include:



4.2.1.5 Change all occurrences of /20 and /22 to /24



4.2.2.1.1 Change all occurrences of /20 to /24, and change 16 /24s to 1 /24. 
Remove the example about 12 /24s.

4.3.2.1  Change both occurrences of /20 to /24

4.9  Change /22 to /24

4.9.1Change all instances of /22 to /24. Remove the reference to 4 /24s.



 6.  Comments:

 a.  Timetable for implementation: Immediate, possibly through 
board action.

 b.  Anything else



END OF TEMPLATE


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

[Richard J. Letts]

I've seen that a new member has joined the ARIN AC each year.

I have not heard concrete evidence that this proposal improves the policy 
making process

I do not think this is a good idea.

Richard Letts
___
PPML
You are receiving this 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-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements

[Richard J. Letts]

 -Original Message-
 From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
 Behalf Of David Farmer
 Sent: Friday, March 21, 2014 3:51 PM
 
 On 3/21/14, 09:10 , Gary Buhrmaster wrote:
  soapbox
 
  Any MA, or organization changes, have a cost regarding business
  records, and it is incumbent on the organization to be prepared to pay
  that cost for changes.  Updating ARIN records (and the cost of doing
  so) is no different, and should not have a special out just because
  it can be take time or the people involved did/do not want to invest
  that effort.  The days of informal handshake number deals are (or
  should be) long over.  Get over it, and do the (boring, painful, but
  necessary) work.
 
  /soapbox
 
 I very much agree, there is and almost certainly should be work involved.
 
 So, yes with any MA, or other organization change, you should have to the
 Business Office part of documenting business records associated with the
 change.  The rationale for this Business Office part is clear.  Its
 necessary to prevent fraudulent changes to resources, and ARIN has a clear
 fiduciary responsibility to ensure this happens correctly.

I also agree that getting the ARIN records updated should be a cost of doing 
business during MA activities; this is the sort of thing that should be able 
to be delegated to the finance/business officers and they should deal with 
whatever is necessary to preserve the assets of the organization. 

I find it frustrating when routing breaks that I can't find the right people to 
contact about it, and sadly IME it's not small companies that are the worst at 
this.

Richard Letts
___
PPML
You are receiving this 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.