[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 Thu, Sep 12, 2013 at 7:37 PM, Owen DeLong <owen at delong.com> wrote:

> >
> >> Plurality seems like an odd choice of word above. The implication is
> >> that if 21% of the equipment for which I use ARIN addresses is in
> >> North America, and as long as my use in each of the other four regions
> >> is 20% or less, I'm good to go.
> >
> > Well more precisely the lowest possible use within the ARIN region is
> some fraction greater than 20%, with less than or equal to 20% in the other
> four regions.  While possible in reality, this is much more of a contrived
> example that something you would expect to see regularly in the real world.
>  However, if you were only operating within the ARIN region and one other
> region you would need greater than 50% in the ARIN region and less that 50%
> in the other region, a simple majority.
> >
>
> As written, I could, for example, have 50.001% in the ARIN region and
> 49.999% in one other RIR and be within the proposed requirements.
>
> However, I think that in a policy like this, it is important to choose
> language which does not limit operator flexibility in unintended ways while
> getting as close as possible to the intended result.
>
> If anyone has language that they believe will better match policy intent
> (or feels that a different intent would be better for that matter), then
> please express those ideas here.
>
> >> That doesn't seem to be what the author was trying to achieve, does it?
> >
> > I'd agree it wasn't what the authors were originally thinking, but if
> you review the earlier comments there were several people that objected to
> a 50% majority, and plurality was suggested as an alternative, as discussed
> in the Advisory Council Comments sections.
> >
>
> Majority is certainly more problematic than plurality. Plurality might not
> be the best possible choice, either, but nobody, including myself, has yet
> proposed a better alternative. The AC would certainly welcome any improved
> language from the community if anyone has a better idea.
>


Why not simply use a phrase like "significant fraction" rather than
"plurality"?

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

(representing a global network that spans 4 RIRs, but has no
customers, I also advocate changing from "and customers"
to "or customers", to relieve networks such as the one I work
for from being unfairly excluded from obtaining ARIN resources.

I will also note for the record that as port density increases,
the number of devices we use is going down, not up.

They cost a metric shit ton more, and suck up more power
and need more cooling--but if you're measuring by "number
of boxes" rather than "capability of boxes", I think the expectation
that the number of boxes in a network will always be increasing,
as someone else further down in the thread claimed, is prima
facie false.

Matt

(for the record, while I'm suggesting alternate language that
I think might be more palatable, as currently proposed,
I oppose this proposal)




> Owen
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130914/14f37b78/attachment.htm>