[arin-ppml] ARIN Draft Policy 2017-3: Update to NPRM 3.6: Annual Whois POC Validation

[hostmaster at uneedus.com]

I did not attend ARIN39, but did watch the video of the discussion 
regarding this Draft Policy.  I have looked thru the archives, and have 
not seen any previous discussion of 2017-3 since its announcement, thus I 
start the discussion on the list.

I am in favor of the policy changes, except for 3.6.7, which would remove 
non responsive contacts from the database.  While I have no issue with 
marking any set of contacts as non-responsive, actually removing the last 
known contact is wrong.  While the information may be stale, and the 
record will state this fact, it still provides an important clue if an 
investigation regarding that record needs to be taken due to law 
enforcement needs or other vital purposes.  Therefore, until a POC is 
replaced with another known good POC for that resource or the resource is 
otherwise revoked, I think the old data should remain for every resource. 
In fact, until the resource is reassigned to a new holder, there may be 
good reason to leave it with a notation it has been revoked, giving LIRs a 
easy way to verify the truth of what might be a forged LOA for the 
resource.

The most important change in this proposal is allowing legacy contacts to 
be updated without the signing of an RSA.  Of course many at ARIN cannot 
understand why legacy holders are not rushing to sign, but looking at it 
from the other side, I fully understand why the lawyers for such firms 
will not allow it.  Please change policy to allow these POCs to update 
their information.  Overall, this will be the best decision.

Of course with IPv6 resources, we are starting with a clean slate and even 
legacy IPv4 holders require a RSA for these resources.  However, on the 
other side of the coin, because of the larger default blocks allocated, it 
might be years, or even decades until they return for more resources, 
making it even more likely than now for POC's to go stale.  Since the 
billing contact is often different than the other network POC's, that does 
not help in keeping the other POC's current.

During the discussion, a major worldwide content management firm disagreed 
regarding removal of notification to downstream assignment contacts who 
have no relationship to ARIN. He found that this is often the only way he 
discovers POC records created by his many upstream ISP's around the world.

Of course this is only a symptom of what is the TRUE issue, which is 
allowing the adding of POC records by upstream ISP's for assignments that 
must be registered at ARIN without first obtaining affirmative consent of 
the contacts who are added.  This is also why the spam laws might be said 
to apply, since these contacts never gave their consent. Changing the 
proceedure to require the POC accept before permitting the record to be 
added is best practice.  Of course such contacts need to be able to edit 
their own POC record, even if there is no contract with ARIN. I understand 
is an operational issue, not a policy issue.  This would also allow the 
contact to steer all such ARIN assignment contacts to a single ARIN 
handle, instead of ending up with one handle per assignment, often using 
an address that was never meant to be used for that purpose.

Removing the requirement for ARIN to validate the downstream assignments 
is best, if needed let the RIR's be in charge of this, as they know their 
customer and the circuits the resources are attached to, and are best 
equipped to keep this part of the database up to date. ARIN resources ar 
better used elsewhere.

Albert Erdmann
Network Administrator
Paradise On Line Inc.