[arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised Problem Statement and Policy Text

[Matthew Petach]

On Tue, Sep 17, 2013 at 11:45 AM, David Farmer <farmer at umn.edu> wrote:

> I'm going to break this up into separate sub threads.
>
>
> On 9/17/13 10:20 , Matthew Petach wrote:
>
>  On Mon, Sep 16, 2013 at 3:59 PM, David Farmer <farmer at umn.edu
>> <mailto:farmer at umn.edu>> wrote:
>>
>>     On 9/14/13 22:58 , Matthew Petach wrote:
>>
> ...
>
>          change
>>
>>         " a plurality of resources requested from ARIN must be justified
>> by technical
>>         infrastructure and customers located within the ARIN service
>> region, and any located
>>         outside the region must be interconnected to the ARIN service
>> region."
>>
>>         to
>>
>>         " a significant fraction of the resources requested from ARIN
>>         must be justified by technical infrastructure or customers located
>>         within the ARIN service region, and any located outside the
>> region must be
>>         interconnected to the ARIN service region."
>>
>>
>>     If we don't like plurality for whatever reason, I'd suggest;
>>
>>     "a minimum of X% of the resources requested from ARIN must be
>>     justified by technical infrastructure or customers located within
>>     the ARIN service region, and any located outside the region must be
>>     interconnected to the ARIN service region."
>>
>>     Where X% is something like 20%, 25%, or 30%.
>>
>>
>> So, how about something like this, then?
>>
>> "a minimum of 20% of the *new* resources requested from ARIN must be
>> justified by technical infrastructure or customers physically located
>> within
>> the borders of ARIN member countries, and any technical infrastructure
>> or customers located outside the ARIN region must be physically
>> interconnected to the ARIN service region"
>>
>
> I will modify the current language adding "new" making it "a plurality of
> new resources requested" before the text freeze, I think that clarifies the
> current intent.  Are there any objections to the "new resources requested"
> language?
>
> However, I'd like to hear more comments in support of a flat 20% standard
> before I'm willing to make that change, as I think that significantly
> changes the intent, at least in the view of some.  As an Individual I'd
> support a flat 20% standard.  But as the primary shepherd for the proposal,
> I'm a little worried we would loose as much or more support than we would
> gain with that change.  So, I need a better read on what the community as a
> whole thinks of a flat 20% standard before making that change.  No matter
> what, I will include that in the questions I take to the floor of the PPM.
>

The concern I have with "plurality" is that that I may not know
with certainty that a new request will meet that definition; I may
intend for it to be split 50/40/10 between ARIN/RIPE/LACNIC
regions; but then upon deployment, discover that the LACNIC
backbone nodes required more space than expected, as did
RIPE, and my split ends up being 40/45/15.  Now it's no longer
a plurality of space in the ARIN region.  It's easier to plan to
hit a target percentage than try to hit a multi-way ratio given
the unpredictable and changeable forces that impact real
world rollouts.



>
> As for some of the other additions I'm not sure "physically located within
> the borders of ARIN member countries" add much verses "located within the
> ARIN service region", or "physically interconnected" vs. "interconnected".
>  In your opinion what do these changes add?


(warning--philosophical weeds ahead; feel free to
ignore anything beyond this point as completely
pointless to the actual topic being discussed)

I always wonder what "the ARIN service region" actually
entails.  I know what country borders are; what do we make
of places like offshore oil platforms (sealand?)--is it covered
by the service region, even if it's not one of the member
countries?  If a business address is listed in the ARIN
'region', but not within the borders of any member country,
does it help the LEA desire prompting this policy?
I realize I'm splitting hairs, so feel free to ignore this
philosophical ramble; under ordinary circumstances,
language like "located within the ARIN region" is good
enough for us, because we're not concerned with political
boundaries and law enforcement jurisdictions.  I just realized
that if the intent is to provide an address so that a particular
LEA can track down wrongdoers, what do we do about the
portions of the ARIN service region that aren't associated
with a specific country?  Or is the ARIN service region
strictly bound by the borders of the countries involved,
and anything outside of that belongs to a different RIR,
or does it float up to the IANA level?  Which service
region does the IP address pool on a jet airliner flying
over the atlantic ocean belong to?  Does the entity
making use of the addresses go out of compliance
if all the aircraft using the IPs leave the ARIN region
at the same time?

Likewise, does the aircraft's network still count as
being "interconnected" to the ARIN region, even
with no physical network layer involved?  If that
counts, is it any different from a network that
runs a VPN link from outside the ARIN region
to a device inside the ARIN region, for the
purposes of claiming the networks are
"interconnected".  For that matter, as long as
the different network elements connect in
some fashion to "the Internet", doesn't that
satisfy the "interconnected" clause, in which
case, does having it in actually add anything
to the policy above simply saying "the number
resources requested must be used on the
Internet somewhere"?

OK.  Enough late-night philosophizing.  Back to
doing some real work.  ^_^;

Matt






>
>
> Thanks
>
> --
> ==============================**==================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ==============================**==================
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130918/da541ea9/attachment.htm>