On 10/8/2013 7:54 PM, John Curran wrote:
On Oct 8, 2013, at 11:23 AM, Matthew Kaufman <[email protected]> wrote:
John, a few clarifying scenarios below, if you would be so kind as to apply
your interpretation both pre- and post-policy to these as well:
...
So if I understand the above response, when Acme Hosting comes and requests
more addresses for the VMs because they have a bunch more Asian customers who
want a local server presence, you would approve now but deny with the new
policy. Correct?
Matthew -
We verify technical infrastructure and customers - this verifying _existing_
assignments already made. Based on that rate of utilization, the requester
will qualify for certain amount of space. Under the new policy, we would
only issuance space such that a plurality of new resources were justified
by the utilization rate of in-region customers extended forward.
And when Acme Hosting, who was doing a brisk business selling VMs to Asian
customers, and now has 55% Asian customers in total comes to you to request a
bunch of IP addresses for VMs that they are selling to a new set of *US based*
customers, you would still approve now but deny (because of the plurality of
existing usage) under the new policy?
Correct, the "intent" of the request for additional IP addresses for new
in-region customers doesn't matter; we'd still look at the existing usage
assigned to customers.
Does the same apply for Acme Websites, who was doing a similarly brisk business with the Asian
market, but not for VMs but instead additional IP addresses on physical hosts used for non-SNI SSL
hosting? Or are their additional IP addresses that they're assigning to physical hardware
interfaces considered by ARIN to be "infrastructure" owned and operated by Acme Websites?
(They do respond to ARP requests on the physical Ethernet segment, so it sure feels like they're
"really there")
We would consider the past utilization of IP addresses assigned to the
equipment in region to determine utilization rate going forward.
How about for Acme Physical Servers, who was also doing a similarly brisk
business with the Asian market, but instead of VMs, was out provisioning actual
physical hardware for these customers? Are those physical servers which are in
use by the Asian customers considered to be customer equipment owned and
operated by Asian customers, or infrastructure equipment owned by Acme Physical
Servers (who not only has physical possession of the servers, but also the root
password and only lets the customers upload website data)?
We would consider the past utilization of IP addresses assigned to the
equipment in region to determine utilization rate going forward.
And what do you do when the above Acme Physical Servers gets approved for the
space, but realizes they can save a bunch of money selling all their cloud
servers on eBay and moving everyone to 1/10th of the remaining machines as VMs?
We generally know how to work with customers who go through equipment
changes, including equipment with higher densities of IP address usage.
FYI,
/John
John Curran
President and CEO
ARIN
I think you didn't answer my implied question, which is:
How do you decide what is "an address assigned to a customer" and what
is "an address assigned to the entity itself for its infrastructure" for
the case of: 1) physical web servers used by an entity; 2) physical web
servers used exclusively by a customer of the entity; 3) physical web
servers with >1 address serving web pages where each address is used
exclusively be a different customer of the entity; 4) physical servers
running >1 virtual server with an assigned address where the virtual
servers are used exclusively by the entity; 5) physical servers running
>1 virtual server with an assigned address where the virtual servers
are used exclusively by customers of the entity.
Me, when I assign addresses to things that I own, they're still my
addresses on my things, no matter who I let use them or for how long...
but it sounds like you have a different interpretation.
Matthew Kaufman
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
