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

[John Santos]

I'm a little confused by this because my company is a legacy holder and 
I'm certain I've updated our POC information several times in the past.  
(At least once because the phone company changed our area code, once 
because the Post Office changed our ZIP code, and one of our original 
POCs retired and I changed our company's administrative POC as a 
result.)  I've also changed our rDNS server addresses several times over 
the years. If it makes any difference, I have been responding to the 
annual "please validate your POC information" email from ARIN.

Am I currently prohibited from making changes, or has maintaining the 
POC information been sufficient to retain my right to update our records?

-- John

On 5/10/2017 1:49 PM, hostmaster at uneedus.com wrote:
> I am opposed to this as well, unless the resources are in fact revoked 
> and reassigned, which in fact, as to legacy resources is never going 
> to happen.
>
> While strictly speaking ARIN does not "have" to provide the reverse 
> records, the legacy holders could argue in court that the service was 
> always provided free from the beginning under USG contract and must be 
> centrally done in order to work, and asking that ARIN be ordered to 
> continue to provide rDNS or turn the records back over to the USG so 
> the legacy holder can continue to receive rDNS.  Im sure ARIN does not 
> want to get into a cost argument over providing a few PTR records, and 
> the risk of an adverse Court decision.
>
> I strongly suspect the real reason the contacts are not being updated 
> is because of ARIN trying to use anything as a stick to force the 
> party to sign an RSA.  If the portion permitting the update of POC's 
> without an RSA is adopted, my guess is a lot of those contacts will 
> update to prevent hijacking.
>
> The Legacy issue will take care of itself when IPv6 becomes the 
> primary protocol.  Some day IPv4 will no longer be routed on the 
> public internet, but I strongly suspect that will be a long time from 
> now.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
> On Wed, 10 May 2017, David Huberman wrote:
>
>> I really appreciate your email and your thoughts, thank you. Do you 
>> have an opinion on the proposal's requirement to remove rDNS 
>> delegation records when POCs go unresponsive? As an advisory council 
>> member, I really want to hear many operator views on the rDNS portion.
>>
>> Thank you,
>> David
>>
>> Sent from my iPhone
>>
>>> On May 10, 2017, at 12:19 PM, hostmaster at uneedus.com wrote:
>>>
>>> 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. 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539