[ppml] Definition of "Existing Known ISP"

[Owen DeLong]

On May 3, 2007, at 1:38 AM, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

>> In general, if you are assigning /32s to customer utilization, but,
> not
>> to independently routed segments (e.g. you have a bunch of customers
>> on the same server each assigned a /32), then, no, you don't meet
>> ARIN's definition of an ISP.
>
> This is news to me.
>
> Since when does ARIN tell ISPs what their business model must be? I
> thought that ARIN's policies required an org to give "technical
> justification" for IP address assignments and that SSL webhosting  
> counts
> as a technical justification. Where does the policy prohibit assigning
> addresses to customers on the same server?

Michael,

It's got nothing to do with business models.  It has to do with  
network topology.
 From an ARIN perspective, reassignments apply to networks, not to host
addresses.

If you're reassigning network segments to other entities, then,  
you're in the
ISP definition. If you're not, then, you're probably in the end-user  
definition.

This has nothing to do with what is or isn't legitimate address  
usage.  It has
to do with a definition of which section of the policy you fall under.

The SSL webhosting counts as technical justification for end user
networks where host counts and technical justification for
efficient utilization within each given network are what matters.  In  
the
ISP section, what matters is the portion of network space you have
assigned/reassigned and that all reassignments and assignments
meet the end-user guidelines for efficient utilization.

In short, ISPs are responsible for conforming to two sets of guidelines
and making sure that their customers conform to one of those two
sets.  End users only have to conform to the one set.

This is an absurd semantic interpretation of my statement and I don't
understand what you think is gained for anyone by muddying the
waters with it.

I have already agreed that the usage of the term ISP in the policy
to represent this concept is a flawed use of the term.  However, absent
a policy proposal to correct that wording (which I believe will probably
come up shortly from another source), this thread was started as
an attempt to clarify the meaning of the term FOR PURPOSES OF
THE EXISTING ARIN POLICY.

It's pretty clear from the context and historical application of ARIN
policy that:

	1.	IPv4 resources issued by ARIN fall into two categories.

		A.	Organizations who issue networks or blocks of networks
			to other organizations (reassignments and/or reallocations).

		B.	Organizations who directly consume network addresses
			on machines owned/operated by the organization, even
			if those addresses are unique to particular customers
			of the organization.

	2.	The primary actual implications of the distinction between these
		policies fall into two categories.

		A.	Membership -- Organizations in category 1A receive
			ARIN membership as part of their resource subscription
			fees. Organizations in category 1B do not.  They can
			purchase ARIN membership as a separate fee.

		B.	Fees -- Organizations in category 1A pay generally
			higher fees based on the total amount of resources
			held by the organization. They do not pay initial
			allocation fees, but, they do pay any applicable
			increase in their renewal fees upon issuance
			of any resource which moves them into a different
			fee category. Organizations in category 1B pay
			a flat fee of $100/year for maintenance of all of
			their resources, but, each request for additional
			resources results in an initial assignment fee
			for said resource(s).

	3.	This distinction is more about how the addresses are treated
		topologically than it is about business models, the actual
		definition of an ISP in the real world, the phase of the moon
		or the price of tea in China.

Now, the question at hand refers to the section of ARIN policy regarding
initial allocations of IPv6 address space.  I believe that the clear  
intent
of the IPv6 policy as written was to make it a no-brainer for ARIN to
issue /32 allocations to any organization known to ARIN as an IPv4
reassigner/reallocator.

Owen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070503/75d11760/attachment.p7s>