[arin-ppml] Incorrect POC on resource records

[Ted Mittelstaedt]

On 9/26/2012 10:01 AM, Steven Noble wrote:
> On Sep 26, 2012, at 9:32 AM, Ted Mittelstaedt <tedm at ipinc.net>
> wrote:
>>
>> Let me just point something out here.
> <snip>
>>
>> The whole concept that Legacy owners do not have a duty and
>> responsibility to maintain correct and valid POCs on IP numbering
>> flies in the face of the overall support the Internet has for
>> knowing who is assigned numbers.
>>
>> In the past, ARIN could sidestep this issue by telling people
>> "well, we are gonna force them to keep their record current because
>> if they don't, and they want more IP numbers, they won't get them
>> until they clean up their records"
>>
>> This had a giant glaring flaw in that not all orgs are under
>> unlimited growth and will ever need more resources - a flaw I and
>> others pointed out with regularity - but it sufficed for most
>> people, so we were ignored.
>
> Did you also point out how hard it is to get things updated in the
> ARIN database?  Once ARIN changes the POC from a real person to their
> POC, the company has to go through hoops to get the information
> updated.  It should be very easy for the original POC to get
> reinstated.

The problem is this runs afoul of the protections that the community
insisted be put into place to guard against malevolent users from
changing the data.

In the olden days, around 2004, it WAS easy - a phone call to hostmaster
would do it - provided that you provided verifiable info.  Alas those
days are gone, now.

I think there's more concern among the community for malevolent people
changing records than for people who accidentally left their records
go stale.  Thus the "good guys" have to jump through hoops.

But seriously this isn't any worse than for example, going to a
bank and getting them to put you on your aged mother's bank account
when she has a stroke and cannot write checks anymore.

  And if ARIN changes the POC without notice then what?
> It now becomes the legacy holders fault?  No.

Yes.  In property ownership there's a concept called adverse
possession that basically states that an org can take over abandoned
property.

It works very easily, you find some property that someone has
abandoned (like property taxes on it haven't been paid for the
last 10 years, etc.) start occupying it, fixing it up, paying
the property taxes on it - then bang, you own it. (after
filing the appropriate paperwork out)

Thus if 10 years later the original owner shows up and demands
their property back they are S.O.L.  It -is- their fault that
they didn't keep things maintained.

In short, in the US at any rate the legal concept of "use it or
lose it" has validity.  Thus I don't see how this concept is
that outrageous.

>
>> But now, since there are no more IPv4 numbers to give out, ARIN
>> can no longer punt this issue down the field.
>>
>> We have orgs using IPv4 resources who are effectively unknown
>> because they don't have to pay a bill every year, and because they
>> have either deliberately or accidentally allowed their contact info
>> on those resources to go stale.
>
> Or they cannot update the contact info as ARIN has changed the POC.
> I guess you have never been on the other side of the table, but I
> have and it's a huge pita once ARIN decides that your record is
> invalid.  You can't update your physical address even if they can
> verify it.  This is a very one sided system.
>

This is an area where a public airing of an actual example would
help clarify your position.  Until such time that you provide it,
I am going to have to side with ARIN, buddy.

>> It is unfair that 98% of users of IPv4 are contractually obligated
>> to maintain contactable information on their IP addressing use, and
>> 2% of them - the legacies - seem to assume they have some sort of
>> right to not do this.  It was always unfair but the community
>> didn't want to face the issue, and allowed ARIN to kick the can
>> down the road.
>
> You are using the unfair argument?  I can't go with you here.
>

Of course you can't because you are operating from the position that
an org should be allowed to put a POC on a resource that is essentially
useless.  Your coming from the position that requiring the 98% of
users to keep their POCs updated is unfair, and that putting a 
punishment into place to convince them to adhere to that requirement
is unfair.  At least that is how you sound.  If I am wrong then
WHAT IS your position?

>> Well, now the community wants more IPv4 - even though there is none
>> left - and the legacies who appear to have abandoned their IPv4
>> resources by deliberately or inadvertently not maintaining valid
>> contact info, are being regarded by many as "fair game"
>>
>> I am very satisfied with this.  Why aren't you?
>
> Because I have been and still am on the other side of this.  Since
> you seem to have never had one of your valid POCs marked invalid, you
> should try it.  Then when you spend 8 years fighting with ARIN over
> it you can tell us what a great system it is.  There are two sides

Provide the story.

Rules and laws are NOT made based on hypothetical situations, despite
what many on this list seem to think.  They are made based on actual
stories.

Tell your story, name names, name dates, provide verifiable info
here, and I am sure people will listen.

During the argument to get 3.6.1 put in, many examples of POCs that
were absolutely silly in the extreme were posted.  There were POCs
that listed UUCP e-mail address and bitnet e-mail addresses, that
were posted.  These were actual examples right out of whois - they
were not hypothetical situations.  ARIN staff even had the decency
to sound embarrassed that they had let it get that bad.

Nobody said who pushed for 3.6.1 that it was perfect.  But nobody
posted any examples from "the other side" as you call it since "the
other side" didn't exist.  Once 3.6.1 was implemented, the "other side"
was created.  If that side has been mistreated, the post the example
and we can put our heads together and see if a policy or an operational
change is needed!

Ted

> Ted.
>
>
>
>
>