[arin-ppml] About needs basis in 8.3 transfers

[Jeffrey Lyon]

That would be easier but my 2014-17 also addresses this issue.

Thanks, Jeff
On Jun 16, 2014 3:04 PM, "Andrew Dul" <andrew.dul at quark.net> wrote:

> On 6/16/2014 11:58 AM, lar at mwtcorp.net wrote:
> > On Sat, 14 Jun 2014 06:59:39 -0700
> >  Owen DeLong <owen at delong.com> wrote:
> >> Nobody is denying resources to organizations that can document need.
> >> I don’t know what your persistent failure is in this regard or why
> >> you are finding it difficult. However, I have yet to see a case where
> >> any reasonable need was turned away by ARIN unless one or more of the
> >> following circumstances existed:
> >>
> >>     1.    The requestor refused to submit sufficient documentation.
> >>     2.    The requestor refused to sign the RSA
> >>     3.    The requestor refused to comply with community developed
> >> policy.
> >>     4.    The requestor’s need was so small that they could not
> >> qualify under policy.
> >>         Note: This last one has been so completely reduced in recent
> >> policy cycles that it is hard to imagine a scenario where it would
> >> apply to any
> >>         but the most deliberate and stubborn of corner cases.
> >>
> >> As such, I’m sorry, but absent your willingness to disclose specific
> >> examples in detail, I find your argument suspect at best.
> >>
> > Owen,
> > I'm sorry but this isn't quite true. I've had an issue myself. My
> > allocation is a /20.
> > 80% used leaves 819 usable addresses. But as you know they get
> > scattered around.
> > In the case that occurred I had a customer that needed a /22 and
> > another that needed a /23.
> > At the time I had a single open /24 and one /26, the rest was
> > non-contingous /27's, 28's
> > and 29's along with individual addresses that were part of static
> > pools. Since 1996 I have
> > totally renumbered my network 5 times. I'm not allergic to moving
> > things but it takes months
> > to coordinate with customers and irritates the h**l out of them. You
> > can't do it every time
> > to have a larger customer need some IP.
> >
> > They were both deployed and working networks. Not pie in the sky. At
> > the time I was only
> > swiping /29 and larger networks. The request was denied because I was
> > not at the 80%
> > usage for the /20 I had. Actually the swipe didn't show any of my
> > pools or infrastructure
> > while I had other documentation the swipe needed to be close before
> > resources were going
> > to be used going through the rest.
> >
> > The staff suggested that I swipe all assignments down to /32's to help
> > and then assign
> > multiple /27's and /28's to the customers get over the 80% hurdle. The
> > customers were
> > unwilling (probably unable) to configure multiple small networks and
> > then loose them
> > when the larger assignment came through and I was unwilling to "dry
> > lab" it just for
> > show. It is ironic that I could show how over 80% of what I was
> > requesting was to
> > be immediately used I couldn't do it on the previous allocation.
> > One customer moved on and the other has been able to take over an
> > allocation to another
> > customer of a single /24. It still has caused problems but it allowed
> > them to get by.
> >
> > It's unfair to blame "ARIN" for this. The staff are applying policy as
> > best they
> > can and when we leave them wiggle room to do what makes sense they
> > seem willing to do it.
> >
> > I feel that the policy has been broken for a long time. I am not in
> > favor of
> > eliminating a needs test but I do feel showing how addresses
> > are needed and how current assignments are not sufficient to meet
> > those needs should be all that is necessary. Even more so with the
> > transfer market. Obviously the challenge is how to write that up as
> > a policy. I would argue that giving the staff more latitude to use
> > some sense is part of the answer.
> >
>
> Perhaps, we should just lower the utilization threshold to at least 50%
> in every allocation.
>
> Andrew
> _______________________________________________
> 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/20140616/45f11026/attachment.htm>