[arin-ppml] ARIN-prop-126: Compliance Requirement

[Scott Leibrand]

I don't think this policy proposal is about IPv4.  There is already an
effective enforcement mechanism there: you can't get more space unless
you're following procedures.  But for IPv6, there is no real enforcement
mechanism to ensure that those who are allocated IPv6 addresses will keep
whois up to date.  The original intent of the author was to give ARIN a tool
to encourage people to keep their IPv6 whois records up to date, even if
they never go back for additional space.

And as I mentioned in another message, most of what you're objecting to is
already policy.  If you want to change that, we'd need a new policy proposal
to do so...

-Scott

On Tue, Jan 11, 2011 at 9:10 AM, George Bonser <gbonser at seven.com> wrote:

>
>
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
> > Behalf Of ARIN
> > Sent: Tuesday, January 11, 2011 5:23 AM
> > To: arin-ppml at arin.net
> > Subject: [arin-ppml] ARIN-prop-126: Compliance Requirement
>
> Opposed.
>
> v4 is dead.  We can quickly get into the realm of diminishing returns
> with this policy where an increasing amount of effort is expended to
> free up a decreasing amount of resources.  Expending more effort on v4
> is probably not a productive use of time.  Also, the potential to create
> an adversarial environment between ARIN and the rest of the community
> with this policy is great.
>
> "If the organization does not voluntarily return resources or update
> reassignment information as requested, ARIN will cease providing reverse
> DNS services and/or revoke any resources issued by ARIN as required to
> bring the organization into overall compliance."
>
> I have enough trouble as it is proving I use IP addresses that are not
> accessible from the Internet (v4 IPs used in VPN communications with
> various third parties, for example).  The notion of "prove to our
> satisfaction that you are complying with the policy or we will break
> your business" doesn't sit well with me.  It seems there is the
> potential for a lot of harm for little good.  Sweeping up crumbs of v4
> space (a /24 here a /24 there) isn't going to do anyone much good and
> the vast majority of the community already does what they can to make
> sure they are in compliance.  We have enough operational problems as it
> is without having to create a potentially adversarial environment with
> ARIN.
>
> " To date the community has not documented or firmly established use of
> an effective enforcement mechanism."
>
> The enforcement happens when additional resources are requested.  If you
> aren't using what you already have to enough of a degree, you are not
> given any additional.  Going back and attempting to revoke already
> issued resources is much more difficult than simply not issuing more.
> Often addresses are used for communications paths that are not visible
> to the general Internet yet must remain globally unique.  Short of
> providing device configurations, I am not sure how I can "prove" that a
> certain /24 or pair of /24's are in use as they may not even be
> announced to the Internet by BGP and may not be "pingable" from the
> Internet yet are in constant use.  There are probably many others with
> the same sort of issue.  It is already hard enough and we already try as
> hard as we can to stay within the guidelines.  Of the people who don't,
> how much space does that actually represent?  I have a feeling this
> policy would generate a large amount of work (and stress) on everyone
> involved for very little benefit.
>
> It would be better, in my opinion, not to consier IPv4 as a viable
> long-term service delivery mode going forward.
>
> _______________________________________________
> 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/20110111/c25c5ceb/attachment.htm>