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, [email protected] 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, [email protected] 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
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
