[arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment

[Owen DeLong]

Larry,

If I understand you correctly, then this policy won’t affect you.

The point of this policy is that if you do a reassignment that produces a new POC for a known organization,
ARIN will make a good-faith effort to contact that organization and make sure the action is valid and in line with said
organization’s expectations.

If you’re reassignments all use existing POC handles within your organization and/or even new POCs that are within your
organization, then you’re going to be the one that gets the verification requests in question (if any). (Existing POCs
don’t get any new verification requests under this proposal, only newly created ones).

An example of the problem this is intended to solve:

XYZ Corp is a large service provider that has many discrete islands of service that get addresses from their transit
providers.

Transit provider Q should be SWIPing these addresses to ORG-ID XYZCORP, but instead creates a new ORG-ID ZZYZX and
new POC (ZZYCONT-ARIN) referencing the purchasing agent at XYZ Corp that signed the paperwork for the circuit order.

In this case, ARIN would match the organization up and send a message to the known contacts of XYZCORP asking them
to validate the new ZZYCONT-ARIN POC. This would allow XYZCORP to either validate the new POC or contact provider Q
and let them know that they need to fix the SWIP.

To put the problem in perspective, I’ve personally spent several hours tracking down and correcting a bunch of these
just in the last two weeks, and, as I stated earlier on the list, it’s been an average of 200 hours per year for the
last 2 years wasted finding and correcting similar provider errors.

Hope that clarifies things. In light of the fact that it sounds like this wouldn’t actually affect your reassign-simple
SWIPs, does that change your position?

Thanks,

Owen

> On Nov 30, 2017, at 14:04 , Larry Ash <lar at mwtcorp.net> wrote:
> 
> I oppose this Policy,
> 
> The result of this would be I would have to pretty much stop SWIP submissions. Many of my reassignments are
> small enough that SWIP is optional anyway. Of the aprox 110 reassignments I have made, 3 have someone there that could
> respond to an issue, one of which for some reason hates ARIN and refuses to have anything to do with them. An additional
> dozen or so might very well send you their email password if you ask and claim to be their email provider.
> 
> I have chosen to SWIP small reassignments for ease of justification if further IPv4 is needed and for transparency to
> the net if an issue arises. Some are multiple geographically dispersed offices of a single enity. Some are multiple
> tenents of a larger multi-tenent building. The IT resources for many of these offices are frequently consultants
> or corporate folks that might be hundreds of miles away. Neither is likely to respond to POC requests.
> 
> That, I though, was the idea for the simple reassignment. I remain the POC for the reassignment and am responsive to
> issues when contacted.
> 
> Larry Ash COO
> Mountain West Telephone
> 123 W 1st St.
> Casper, WY 82601
> Office 307 233-8387
> 
>>> Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment
>>> Problem Statement:
>>> Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies.  The POC often does not know who ARIN is, what Whois is, and why they are in Whois.
>>> This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly inserted into Whois.
>>> It also seeks to mitigate the significant amount of time that ARIN staff reports that they spend fielding phone calls from POCs who have no idea they are in Whois.
>>> Finally, it is hopeful that this proposal will improve the overall POC validation situation, by forcing ISPs and customers to work together to insert proper information into Whois at the time of sub-delegation.
>>> Policy statement:
>>> Insert two new sections into NRPM 3:
>>> 3.7 New POC Validation Upon Reassignment
>>> When an ISP submits a valid reallocation or detailed reassignment request to ARIN which would result in a new POC object being created, ARIN must (before otherwise approving the request) contact the new POC by email for validation. ARIN's notification will, at a minimum, notify the POC of:
>>> - the information about the organization submitting the record; and
>>> - the resource(s) to which the POC is being attached; and
>>> - the organization(s) to which the POC is being attached.
>>> If the POC validates the request, the request shall be accepted by ARIN and the new objects inserted into Whois.  If the POC does not validate the request within 10 days, ARIN must reject the request.
>>> 3.8 Downstream Validation of Simple Reassignments
>>> When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment.
>>> Comments:
>>> Timetable for implementation: Immediate
>>> _______________________________________________
>>> 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.
>> _______________________________________________
> 
> _______________________________________________
> 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.