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

Wed May 10 13:49:11 EDT 2017

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.
>> _______________________________________________
>> 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.
>>
>
>