[arin-ppml] Incorrect POC on resource records

[Aaron Dudek]

That doesn't apply to Pre-ARIN allocated space (legacy) assuming that
the owner has not required any new services from ARIN, which would
then require the updated agreement.

On Wed, Sep 26, 2012 at 11:01 AM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> On 9/26/2012 7:00 AM, Martin Hannigan wrote:
>>
>> On Wed, Sep 26, 2012 at 3:25 PM, Steven Noble <snoble at sonn.com> wrote:
>>>
>>> On Sep 26, 2012, at 5:05 AM, Martin Hannigan <hannigan at gmail.com> wrote:
>>>>
>>>>
>>>> Small problem. I'm not making any judgements, just stating facts.
>>>> Legacy addresses have value. Many believe that they are property.
>>>> There is law around abandoned property. ARIN has a responsibility to
>>>> make sure that this does not happen. Think of it like the equivalent
>>>> to a bank deposit. Banks have a responsibility to insure the safety of
>>>> your assets and so does ARIN. It's called stewardship. ARIN has a
>>>> responsibility to re-unite legacy block owners with their block or
>>>> ASN, not the other way around. And if they can't, then the State will
>>>> be the final arbiter.
>>>
>>>
>>>  From my dealings with this subject I believe the way ARIN has handled
>>> legacy (and even post-ARIN) assets does not align with your interpretation
>>> of Stewardship.
>>>
>>> Unlike banks (lets not go down the one off cases), ARIN takes actively
>>> used assets and tags them as abandoned or "No, Contact Known", requiring the
>>> original owner to go through hoops to regain control of the asset that they
>>> originally had.  This is claimed to be done to protect the original owner
>>> from forgery and asset theft.  Whatever the logic is, the fact is, it cannot
>>> be compared to any other system of protection that I know of.
>>>
>>
>> I agree with taking "an" action to protect the original owner from
>> forgery or theft.
>>
>> And I used the bank account analogy not to start the inevitable giant
>> thread of incompatible analogies, but because it fits best. A bank
>> account are bits in a computer with nothing physical to touch or feel,
>> much like an address. The account, like a prefix, may be affected by
>> bad record keeping regardless of who's fault it was, the owners or the
>> steward. Both require a chain of custody examination to regain the
>> original rights.
>>
>>> I question the validity of modifying ORG records to say "No, Contact
>>> Known" with an ARIN created POC.  In some cases the real POC _is_ known but
>>> has not been sufficiently re-vetted by ARIN causing a real POC to be
>>> replaced with a ARIN created wrong POC which IMHO makes the ARIN database
>>> unreliable.  It's one thing to label the asset as un-verified but it's a
>>> whole other issue to replace the real ORG POCs with known wrong one such as
>>> CKN23-ARIN.
>>>
>>> OrgTechHandle: CKN23-ARIN
>>> OrgTechName:   No, Contact Known
>>> OrgTechPhone:  +1-800-555-1234
>>> OrgTechEmail:  nobody at example.com
>>> OrgTechRef:    http://whois.arin.net/rest/poc/CKN23-ARIN
>>>
>>> The TechName, TechPhone and TechEmail are all invalid, something that
>>> would (or should) not be tolerated from any ARIN customer, including ARIN
>>> themselves.
>>>
>>
>> Yep. I agree. ARIN should never break a record that may not be broken.
>> Failure to respond does not mean that the contact info isn't correct
>> already.
>>
>
> Sorry, but the address user is required to respond.  When they signed the
> RSA the RSA requires them to supply POCs.  By allowing a POC to become
> invalid they are no longer supplying the POC and are thus in
> violation of the contract.
>
> In any case, if an org deliberately ignores an invoice, their account
> with ARIN runs in arrears and they lose the assignment.
>
> If an org pays an invoice sent to the POC address then they ARE responding.
>
> Obviously, there is a problem with POCs that have valid contact info
> but then simply ignore letters and e-mails sent to that POC unless
> those letters or e-mails come from ARIN.  But, in those cases, since
> they aren't in violation of the contract they signed, ARIN cannot
> do anything.
>
> The issue are the so called Legacy assignments made pre-ARIN that there
> is no RSA on file for.  However, the NRPM requires ARIN to mark these
> as invalid if the POC fails to respond.
>
> So while your opinion may be that ARIN should never break a record,
> the NRPM says otherwise.
>
> Frankly, I see absolutely no benefit to the community to allow POCs
> to remain in WHOIS that do not respond to anyone.  At least, if the POC
> is responding to ARIN but nobody else, that is some justification for
> leaving them in there.  But if they don't even respond to ARIN?
>
> Screw 'em!
>
> Ted
>
>
>> Best,
>>
>> -M<
>>
>
> _______________________________________________
> 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.