[ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested

[Ted Mittelstaedt]

I am opposed to this policy for the following reasons:

1) No public mechanism is specified for proof of utilization.  The requestor
is required to prove to ARIN
they have efficient utilization.  The requestor is not required to
publically publish to the world efficient
utilization.  Under this policy a requestor could make a single SWIP entry
for a /23 allocated to
Wonklulating Gronkulator corporation, with this corporation not registered
in any government entity, not
carrying a business license of any kind, no website, and a telephone number
that rings the phone in
the local public school's janitor's closet. - and that would be perfectly
fine.

Sure they may be required to demonstrate to ARIN efficient utilization of
the /23 - maybe they tell ARIN
that Wonkulating is a cover alias for the CIA or some such - but I don't
care for this
cloak and dagger stuff.  The existing SWIP/RWHOIS is adequate to demonstrate
efficient utilization and
requestors should be required to use this mechanism, and extend it when
appropriate.  If it cannot be publically
proved to most people's satisfaction with entries in SWIP and RWHOIS that a
particular block is efficiently
utilized - then the requestor hasn't met the requirements, simple as that.

2) No mechanism is specified for continuing proof of 100% utilization.
Suppose for example a requestor
demonstrates efficient utilization and gets their /16 under these increased
requirements.  Then 2 years
later they go bankrupt and for the next 10 years a bankruptcy court is
paying the registration fee for the
addresses.

The whole point of this proposal is to tighten IPv4 requirements because the
author is assuming that
the current requirements are loose enough that over the years a lot of
"slop" has accumulated in addresseing
that is already assigned.  In other words it is easier to just request more
blocks than vacuum out the
corners of your network looking for the usable /25 or so and combining them.
I don't know that I agree with
this but for the moment lets assume it's a valid supposition.  If so, it is
then illogical to require requestors to
jump through hoops cleaning up their allocations then once more numbers are
handed out, they ride off into
the sunset and go right back to their slovenly ways.

Statements in the policy exist like "demonstrate a one year requirement of
90% utilization"  But no mechanism in
the policy exists for going back to the requestor a year after they get
their /8 and seeing if they actually DID
use 90% - and if they didn't, then taking some of that allocation back.

Note that I am not opposed to the IDEA of trying to increase the size of the
stick and the carrot to convince
heavy consumers of IPv4 to "mend their ways" and see the IPv6 light.  But
this policy is like a roosters
mouth - much sound and it has no teeth at all.  Give the thing some dentures
at least, for crying out loud.

Ted
  -----Original Message-----
  From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Bill Darte
  Sent: Tuesday, October 02, 2007 2:11 PM
  To: ppml at arin.net
  Subject: [ppml] IPv4 Soft Landing - Discussion and
Support/Non-SupportRequested


  Hello,



  As shepherd of the ARIN Policy Proposal: IPv4 Soft Landing, I would like
to ask the community to once again consider this proposal in advance of the
Albuquerque Public Policy and Membership Meetings
(http://www.arin.net/ARIN-XX/index.html) and voice support or non-support
for this proposal with concise reasoning. More information about this
proposal and other active proposals can be found at
http://www.arin.net/policy/proposals/proposal_archive.html



  Such an effort will refresh this discussion and perhaps air more recently
conceived viewpoints.  It will also aid the Advisory Council in their
efforts to assess industry consensus about this proposal.



  Thank you for your interest and involvement in the ARIN Internet Resource
Policy Evaluation Process (IRPEP).  More information about IRPEP can be
found at http://www.arin.net/policy/irpep.html





  Bill Darte

  ARIN Advisory Council


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20071003/ddf23c37/attachment.htm>